This project is mirrored from Pull mirroring updated .
  1. 23 Jun, 2017 1 commit
    • Seigo Nonaka's avatar
      Stop loading other package's font by default. · 80f6a985
      Seigo Nonaka authored
      Since CONTEXT_RESTRICTED is not a default flag of createPackageContext,
      we can't rely on it for preventing unexpected font injections.
      To protect developers and existing apps from a risk of font injection,
      stop loading font from other package's resouce unless the developer
      explicitly set CONTEXT_IGNORE_SECURITY.
      This CL contains Iac2a6fb3d82ef23d5ca6ee33f4aaa9ed28455271 by manual
      merging to handle repository split.
      Bug: 62813533
      Bug: 62879353
      Test: Manually done
      Merged-In: I4442ddc48dadb5c968b444be86038b602074d301
      Change-Id: I4442ddc48dadb5c968b444be86038b602074d301
  2. 12 May, 2017 1 commit
  3. 19 Apr, 2017 2 commits
    • Chad Brubaker's avatar
      Address API review comments for registerReceiver · 6d6015f6
      Chad Brubaker authored
      Bug: 37465538
      Test: manual; Verified that Instant Apps can send broadcasts to
      receivers still via the changed API.
      Change-Id: Ib0f3d0c8ee71234288ccecd07e621554eb9b70ac
    • Chad Brubaker's avatar
      Change ANDROID_ID for Instant Apps · 0d277a7b
      Chad Brubaker authored
      ANDROID_ID for Instant Apps now has the following properties:
      1) per-app scoped
      2) reset if the user clears the Instant App
      3) remains the same if the Instant App gets upgraded to an installed
      Note that if the user goes instant -> installed_1 -> uninstall ->
      installed_2 the ANDROID_ID at installed_1 will not be the same as
      installed_2. This was deemed better than the id changing on the upgrade
      Test: manual
      Change-Id: I532975c50049c94ff80902a897e001dd35a69f9f
  4. 18 Apr, 2017 1 commit
  5. 17 Apr, 2017 1 commit
    • Christopher Tate's avatar
      Turn down the preliminary foreground service API · 242ba3e9
      Christopher Tate authored
      The NotificationManager.startServiceInForeground() experiment is over,
      and will not ship as API, so it's time to tidy up and get rid of it.
      Bug 36130212
      Test: manual
      Change-Id: I834d1ce059aa464ff27f69f5e5d3625cc5e61d8a
  6. 14 Apr, 2017 1 commit
  7. 31 Mar, 2017 1 commit
  8. 30 Mar, 2017 1 commit
    • Christopher Tate's avatar
      API refactor: context.startForegroundService() · 08992ac5
      Christopher Tate authored
      Rather than require an a-priori Notification be supplied in order to
      start a service directly into the foreground state, we adopt a two-stage
      compound operation for undertaking ongoing service work even from a
      background execution state.  Context#startForegroundService() is not
      subject to background restrictions, with the requirement that the
      service formally enter the foreground state via startForeground() within
      5 seconds.  If the service does not do so, it is stopped by the OS and
      the app is blamed with a service ANR.
      We also introduce a new flavor of PendingIntent that starts a service
      into this two-stage "promises to call startForeground()" sequence, so
      that deferred and second-party launches can take advantage of it.
      Bug 36130212
      Test: CTS
      Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
      (cherry picked from commit 79047c62)
  9. 28 Mar, 2017 1 commit
    • Chad Brubaker's avatar
      Chad Brubaker authored
      This Intent will be used in Settings to show the settings UI for the
      Ephemeral resolver. Settings can get the correct component to send the
      Intent to by calling
      Bug: 35918998
      Test: Boots
      Change-Id: I0edcf85704f2c19e0ee27f91b6ef057d52e32778
      (cherry picked from commit aa49cb86)
  10. 15 Mar, 2017 1 commit
    • Todd Kennedy's avatar
      Add API to mark apps that have an update available · ab53289c
      Todd Kennedy authored
      Ostensibly for instant apps, we allow play to mark an app as having
      an update available. This will trigger instant app resolution even
      if the instant app is already installed on device.
      Bug: 35143464
      Test: Manual; launch URI of installed instant app, see it runs w/o resolution. set bit. launch URI of installed instant app, see it runs resolution
      Change-Id: I511df2b2a3eab39377167c770255ccbe02d5dad2
  11. 07 Mar, 2017 1 commit
    • Chad Brubaker's avatar
      Enforce visibleToInstantApps for receivers · 816c83bf
      Chad Brubaker authored
      Instant apps can only send broadcasts to receivers that are declared in
      the manifest with android:visibleToInstantApps=true or if the app
      registers a receiver at runtime using the new methods that take
      Test: Manually sending broadcasts from Instant Apps only goes to
      receivers with visibleToInstantApps set to true.
      Test: Receiving a broadcast from within the same app does not require
      visibleToInstantApps to be set.
      Change-Id: I54d79a502ba9c5fd03ede3c09e08afc88fe2775f
  12. 02 Mar, 2017 1 commit
  13. 22 Feb, 2017 2 commits
  14. 17 Feb, 2017 2 commits
    • Fyodor Kupolov's avatar
      API for accessing preloaded files cache · 61221290
      Fyodor Kupolov authored
      Added @SystemAPI method Context.getPreloadsFileCache.
      Bug: 31008665
      Test: manual
      Change-Id: Id61ab5e1b78d8bfbd40f61985406a8de4082b30f
    • Andrii Kulian's avatar
      Report move to display for activities that handle config changes · b047b8bd
      Andrii Kulian authored
      When activity that is moved between displays handles all configuration
      changes, it won't be restarted. This CL adds a callback to the client
      to notify it about display change. Usually it will be followed by
      onConfigurationChanged, except when configuration didn't actually change.
      When activity is recreated, it won't receive onMovedToDisplay.
      Bug: 34862802
      Test: android.server.cts.ActivityManagerDisplayTests
      Test: #testOnMovedToDisplayCallback
      Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe
  15. 14 Feb, 2017 1 commit
    • Todd Kennedy's avatar
      Add API to track package changes · 9106c64b
      Todd Kennedy authored
      After any package install, removal or update, save the changed
      package and update a global sequence number. At any point, apps
      can query for the packages changed since a particular sequence
      If a package is changed multiple times, it is only included once
      in the change list.
      Bug: 33865505
      Test: Create sample app to query for changes and see which packages are changed after performing certain operations
      Change-Id: Ia4646035362b16a97110e05f3f909ce385b48428
  16. 09 Feb, 2017 1 commit
  17. 08 Feb, 2017 1 commit
  18. 07 Feb, 2017 1 commit
  19. 31 Jan, 2017 1 commit
    • Svetoslav Ganov's avatar
      Add instant cookie APIs · 096d304a
      Svetoslav Ganov authored
      This change adds APIs for instant apps to store cookie data
      that is presisted across instant installs and across the
      upgrade from an instant to a standard app. Standard apps
      can use the cookie APIs but when they are uninstalled the
      cookie is also deleted. The cookies are kept longer than
      the instant apps as they are much smaller - 16KB by default.
      We can change the cookie size via a system setting i.e.
      after we ship we can increase size if needed.
      We also add internal APIs to surface information about
      installed and uninstalled instant apps which should be
      used for showing them in the UI. For this puporse we store
      the icon, permissions, and label of uninstalled apps. If
      the app is re-installed we drop this meta-data but keep
      the cookie around. If we have cookie data stored and the
      signing cert of the app changes when it gets re-intalled
      we wipe the cookie.
      Test: CTS tests pass; hiddent APIs tested manually
      Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5
  20. 27 Jan, 2017 1 commit
  21. 26 Jan, 2017 1 commit
    • Suprabh Shukla's avatar
      Adding an api for apps to check whether they can install apps · aef2513c
      Suprabh Shukla authored
      Some apps may want to check whether they are trusted to install apps on
      the device, so they can prompt the user to go to settings and mark them
      as trusted before they do an intensive operation like downloading an
      Test: cts-tradefed run cts -m CtsExternalSourcesTestCases
      Bug: 31002700
      Change-Id: Icd9d04daa157e6733decba245ec251ce4acd4122
  22. 25 Jan, 2017 1 commit
    • Adam Lesinski's avatar
      Add support for Split APK dependcies · 4e862815
      Adam Lesinski authored
      Apps can now declare in their base APK AndroidManifest.xml
      that they want to have their split APKs loaded in isolated
      Contexts. This means code and resources from the split
      get loaded into their own ClassLoader and AssetManager.
      <manifest xmlns:android="..."
      In order to make this more useful, splits can declare dependencies
      on other splits, which will all get pulled in to the Context
      and run as expected at runtime.
      A split declares its dependency on another split by using the
      tag <uses-split> in its AndroidManifest.xml:
      <manifest xmlns:android="...">
          <uses-split android:name="feature_split_1" />
      A split can have a single parent on which it depends on. This is
      due to the limitation of having a single ClassLoader parent.
      All splits depend on the base APK implicitly.
      PackageManager verifies that no cycles exist and that each dependency
      is present before allowing an installation to succeed.
      The runtime will then load splits based on the dependencies.
      Given the following APKs:
      base <-- split A <-- split C
        ^----- split B
      If an Activity defined in split C is launched, then the base,
      split A, and split C will be loaded into the ClassLoader defined
      for the Activity's Context. The AssetManager will similarly be loaded
      with the resources of the splits.
      A split can be manually loaded by creating a Context for that split, defined
      by its name:
      All installed Activities, Services, Receivers, and Providers are accessible
      to other apps via Intent resolution. When they are instantiated, they are
      given the appropriate Context that satisfies any dependencies the split they
      were defined in stipulated.
      Test: WIP (CTS tests to come)
      Change-Id: I8989712b241b7bc84381f2919d88455fcad62161
  23. 22 Jan, 2017 1 commit
    • Svet Ganov's avatar
      Platform support for static shared libraries · 6788212d
      Svet Ganov authored
      This change adds support for static shared libraries that
      emulate static linking allowing apps that statically link
      against the same library version to share a common
      implementation. A library is hosed by a package in a standard
      Static shared libraries have a name and a version declared
      by a dedicated manifest tag. A client uses also a new tag
      to refer to the static library it uses by specifying the
      lib name, version, and the hash of the signing certificate.
      This allows two apps to rely on two different library versions
      and prevents impersonation of the shared library by a side-loaded
      app with the same package name.
      Internally apps providing static libs use synthetic package
      name generated from the manifest package name and the library
      version. This allows having different "versions" of the same
      package installed at the same time.
      An application cannot be installed if a static shared lib it
      depends on is missing. A used shared library cannot be uninstalled.
      Shared libraries can rotate certificates like normal apps. The
      versions of these libs should be ordered similarly to the version
      codes of the hosting package. Such libs cannot use shared user
      id, cannot be ephemeral, cannot declare other libraries, cannot
      rename their package, cannot declare child-packages. They must
      target O SDK. Also they cannot be suspended or hidden or their
      uninstall blocked. Generally, speaking policy regarding code in
      static shared libs should be applied to the packages using the
      library as it could have just statically linked the code.
      We now have APIs to query information about the shared libraries
      on the device in general. To clients static shared libraries are
      presented as multiple versions of the same package which is how
      they are declared and published. Therefore, one can have two
      versions of the same package which means we need way to query
      for and uninstall a specific version of a package. Also static
      shared libs can depend on other static shared libs which are
      versioned packages. To ease representation we add the concept
      of a versioned package which should be used in the case of
      static shared libs.
      A client can see only the static shared libs it depends on and
      more specifically only the versions it depends would be retrieved
      by using the standard package manager APIs. There is a new
      dedicated API to get info about all shared libraries which
      would provide data about all static shared lib versions. Also
      these libraries must use v2 signing scheme.
      Test: CTS tests pass
      Change-Id: I4f3d537ee7a81f880950377b996e1d9d4813da5c
  24. 20 Jan, 2017 1 commit
    • Christopher Tate's avatar
      Enable background restrictions · 42a386b7
      Christopher Tate authored
      Apps that target O+ are always subject to background restrictions.
      Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
      app op.
      Apps with these properties are exempted from background restrictions:
        - persistent process
        - currently on the idle battery whitelist
        - global whitelist for things like bluetooth services
      Bug 30953212
      Change-Id: Icc19b2fbc05f40dcf8c3fc4abf718c373dc8d4f6
  25. 19 Jan, 2017 2 commits
    • Paul Duffin's avatar
      Prepare for removal of legacy-test from default targets · ccb04450
      Paul Duffin authored
      In preparation for removing junit classes from the Android API
      the legacy-test target will be removed from the
      TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
      dependencies on junit and/or legacy-android-test to ensure that
      modules will compile properly once it is removed.
      (cherry picked from 6387604f9e672ece85e07c4bcbd7be396867f06f)
      Bug: 30188076
      Test: make checkbuild
      Merged-In: I13e88297731253420e4e5f5291d503f13a39a156
      Change-Id: I58446eb8c45d8ac2bcdbc9fa40d1321e811bdd4b
    • Chris Tate's avatar
      Revert "Enable background restrictions" · 9e83cbbc
      Chris Tate authored
      This reverts commit 21f77806.
      Change-Id: I65586f9739da84fb32b51b0ea166b8288c41d1b3
  26. 18 Jan, 2017 2 commits
    • Christopher Tate's avatar
      Enable background restrictions · 21f77806
      Christopher Tate authored
      Apps that target O+ are always subject to background restrictions.
      Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
      app op.
      Apps with these properties are exempted from background restrictions:
        - persistent process
        - currently on the idle battery whitelist
        - global whitelist for things like bluetooth services
      Bug 30953212
      Change-Id: Ib444829a2d222125f64ff19e8218823fa78373f9
    • Paul Duffin's avatar
      Prepare for removal of legacy-test from default targets · 8aeb59eb
      Paul Duffin authored
      In preparation for removing junit classes from the Android API
      the legacy-test target will be removed from the
      TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
      dependencies on junit and/or legacy-android-test to ensure that
      modules will compile properly once it is removed.
      Bug: 30188076
      Test: make checkbuild
      Change-Id: I13e88297731253420e4e5f5291d503f13a39a156
  27. 13 Jan, 2017 1 commit
    • Bartosz Fabianowski's avatar
      Add install reason · a34f53f6
      Bartosz Fabianowski authored
      This CL allows a reason to be specified when installing a package. The
      install reason is a sticky piece of metadata: When a package is e.g.
      installed via enterprise policy and an update is then manually
      installed or sideloaded, the install reason will remain "policy."
      The install reason is tracked separately for each user.
      With this CL, two install reasons exist: "policy" and "unknown." Other
      install reasons will likely be supported in the future.
      Bug: 32692748
      Bug: 33415829
      Test: Tested manually with "adb install" / "adb uninstall"
      Change-Id: I0c9b9e1b8eb666bb6962564f6efd97e41703cd86
  28. 12 Jan, 2017 1 commit
    • Jeff Sharkey's avatar
      Add API for apps to declare their "category". · 9bc89af3
      Jeff Sharkey authored
      Upcoming platform features need to cluster apps together into broad
      categories to help summarize information to users.  (For example,
      when presenting battery, network, and disk usage.)
      We are tightly limiting the set of categories to keep them easily
      presentable to users when summarizing information.  This feature is
      not designed to be a general-purpose taxonomy, nor should it be
      allowed to become one.
      Older apps may not have defined a category in their manifests, so
      allow the installing app to define a category on their behalf.
      Test: builds, boots
      Bug: 33815939
      Change-Id: I785b882ee7c18072ef47d56e0fc19ad72888e1b7
  29. 29 Dec, 2016 1 commit
  30. 14 Dec, 2016 1 commit
    • Paul Duffin's avatar
      Copy junit-runner files into test-runner. · eef35dd2
      Paul Duffin authored
      The android.test.runner target forms part of the Android API and
      so must maintain backwards compatibility. The junit classes that
      belong in there are copied here to ensure that they do not
      change when external/junit is upgraded.
      Bug: 30188076
      Test: make checkbuild and checked android.test.runner contents
      Change-Id: I947144c47ae1c3eb361a43c39bdd03dc11b9575f
  31. 09 Dec, 2016 1 commit
  32. 06 Dec, 2016 1 commit
  33. 29 Nov, 2016 1 commit
    • Kenny Guy's avatar
      Allow overriding max profile in debugable builds. · 02c8990b
      Kenny Guy authored
      Support a system property on debugable builds to
      override the max number of managed profiles to
      allow easier dogfooding of multiple profiles.
      Support 3 different badge colours for managed profiles.
      Bug: 30473760
      Test: runtest -c frameworks-services
      Test: runtest -c frameworks-services
      Test: manual - attempting to create 2 profiles with adb fails, passes once I set the property.
      Change-Id: Ie7fb19048a04a01572666f229283152254d0ffc3
  34. 22 Nov, 2016 1 commit
    • Paul Duffin's avatar
      Move JUnit classes from here into external/junit · 0342ab5b
      Paul Duffin authored
      Checked that android.test.runner had the same classes in as
      before the change.
      These classes are legacy 3.8.1 classes, they are not in 4.10 at
      all. They appear to have been left here by accident. Looking at
      the history it appears that at one time there were copies of
      JUnit 3.8.1 junit.runner classes in frameworks and
      external/junit. The classes here were upgraded to 4.10 but even
      though these classes had been deleted immediately after 3.8.2
      was released they were not removed, instead they appear to have
      been reformatted as part of the upgrade. The external/junit
      source was upgraded to 4.10 about two weeks later which seems to
      have been done correctly. About three months after that the
      classes here that were duplicates of those in external/junit
      were removed from here leaving the legacy classes from 3.8.1.
      I could not find any usages of these classes and they are not in
      the public API so they can probably be removed altogether.
      However, for now I will simply move them into external/junit as
      described and remove them when upgrading JUnit there to 4.12.
      Bug: 30188076
      Test: Built android.test.runner and checkapi
      Change-Id: I88687889315c041d999fe7e61b9652ac8406165c
  35. 17 Nov, 2016 1 commit
    • Bartosz Fabianowski's avatar
      Wire up PM.getInstalledApplicationsAsUser(flags, userId) as hidden API · 1133424c
      Bartosz Fabianowski authored
      Settings needs to access a variant of getInstalledApplications() which
      takes a |userId| argument. Since this is not currently exposed by
      PackageManager, Settings calls into PackageManagerService directly. This
      is ugly and breaks the regular abstraction layer hierarchy.
      The CL fixes the problem by exposing the required variant of
      getInstalledApplications() as a hidden API, analogously to what was done
      before with getInstalledPackages().
      Bug: 32692748
      Test: Will be CTS-verifier-tested together with Settings
      Change-Id: Id9c4e8e18524d312159821f1a4d5527263c7e950