To help investigate performance regressions, an option is added to
'adb shell cmd package compile' to compile all packages with the
given mode.
Bug: 27391290
Change-Id: I70a3a518e08b54535bb34f13f0cedda3a1f7085f
Since the data returned by these calls can grow unbounded based on
various GET flags, we need to switch 'em over.
Bug: 27391893
Change-Id: Ie849ca30dbaaa91158da4c83675657715629a0ee
Make referenced constants @SystemApi and change argument name to
match its actual meaning.
bug: 25441401
Change-Id: I4277799b95f394edb4305be05f57437717a86691
It allows badging an image regardless of of the user (no
user id parameter). The styling for managed users is applied.
This is useful for new cases where the existing functions
wouldn't badge the icon, but we need it.
Bug: 25192539
Change-Id: I2fd2f226f626fb2e6cda1cfe072013350e12b41c
From the runtime perspective extract-only/profile-guide-compiled/fully-
compiled oat files are up-to-date and don't need dex2oat. However,
wihout knowing the exact "class" of the aot file we are not able to do a
full compilation of something previously only-extracted, or limit
profile-guide compilation to only previously profile-guide or extract-
only oat files.
GetDexOptNeeded now accepts a mask of desired types of compilation
that the runtime takes into account when advising what's needed.
This CL adds the necessary handling in DexOptimizer.
Also:
- removes the contraint to use extract-only oat files only when
profiles are enabled.
- removes mDexOptPerformed which interfere with the different types of
compilation and only saved a call to GetDexOptNeeded.
Bug: 27189430
Change-Id: Iced2bdcc3aa7866ff888a3bace43f4b71fffb353
In specific cases [as determined by the installer], we can install
splits without restarting the application. The split must be purely
additive [i.e. it should not modify class(es)/resource(s) defined
in the base or other splits. Otherwise, the behaviour could be
inconsistent [e.g. if a modified class was already loaded, the
modified version won't be loaded until the process is restarted].
The platform does not perform any verification that the split is
purely additive.
Bug: 26463098
Change-Id: I3526c3b1b847a8e0afabc7a4787fa770422196b7
In order to satisfy the requirement that clients can
cache a Resources object when a configuration change happens,
we move the caches and all other method bodies to ResourcesImpl.
These can then be swapped out for the correct version when needed,
while allowing clients to keep holding the existing Resources references.
This is part 1 of 2 CLs. The next one will do the actual switching of implementations
based on configuration changes for multiwindow.
Bug:26854894
Change-Id: I41156194a3541e59053b4048c3a15981c7d8a506
It allows badging an image regardless of of the user (no
user id parameter). The styling for managed users is applied.
This is useful for new cases where the existing functions
wouldn't badge the icon, but we need it.
Bug: 25192539
Change-Id: I20ca2d7265cbc3a47c050a72ec1843cc0a481c74
Ensure we're using file paths from the correct package. Also cleans up
synchronization to avoid synchronizing on local variables which, while
not an issue in the current implementation, is generally unsafe.
Bug: 27313689
Change-Id: Ib8550909e7b02ea88d19ce2fc43756a16f9664ab
Similar to first patch, but now using new "rethrowFromSystemServer()"
method which internally translates DeadObjectException into
DeadSystemException. New logic over in Log.printlns() now
suppresses the DeadSystemException stack traces, since they're
misleading and just added pressure to the precious log buffer space.
Add some extra RuntimeInit checks to suppress logging-about-logging
when the system server is dead.
Bug: 27364859
Change-Id: I05316b3e8e42416b30a56a76c09cd3113a018123
An attacker could downgrade a package to an older version with known
security vulnerabilities and then use some of the vulnerabilities to
access the application's data. This would constitute a bypass of
Android Application Sandbox. Thus, downgrading while keeping
application data is no longer permitted.
To help developers debug their apps, packages marked as debuggable can
still be downgraded while keeping their data. This does not put the
installed base at risk because, as a security measure, most
application stores reject packages marked as debuggable.
To downgrade a non-debuggable (i.e., release) package, uninstall the
package (thus wiping its data), then install the older version of the
package.
Bug: 27327503
Change-Id: Iac75ed3c3831b5d925dfd8b660527cfa95813da8
Once the ephemeral user stops, the user's deletion is scheduled.
It takes a while before the user actually disappears and it is not
desirable for the user to be re-entered in the meantime.
Mark the user as disabled on stop and check this flag
in the activity manager to prevent the user from being switched
to again. Also hide the user from user-switching UI.
BUG: 26795729
BUG: 26780152
Change-Id: I83a61674958954b5a210114b88ffa5ae55922c1f
Developers usually do not need to check the result of getDrawable(), so
we shouldn't be annotating it like they do.
Bug: 27134828
Change-Id: I0db0ca806fd89c18781da452fe3f31ef344f3cca
There are some permissions that were removed from the platform
and guard nothing but legacy apps may be checking them before
calling APIs. Hence, these apps should get the permissions as
expected despite them being a no-op. To address this the platform
declares removed permissions as normal permissions that are hidden
such that legacy apps can always get them. These permissions are
not shown in the UI. Play needs a way to filter out these
permissions like the platform as they have permissions UI too.
bug:23361760
Change-Id: I10f442dfc09a299ddc5480d8bf2db0bd786aec62
FEATURE_VULKAN_HARDWARE_FEATURES describes the feature set supported
by the device hardware and driver. FEATURE_VULKAN_HARDWARE_VERSION
describes the Vulkan API version supported by the driver, which may be
lower than the API version supported by a particular Android release.
Bug: 26583896
Change-Id: Ia3e6be496abf631cb677eb838d632d3c7b4dd24b
Add a separate system service RecoverySystemService to handle recovery
related requests (calling uncrypt to de-encrypt the OTA package on the
/data partition, setting up bootloader control block (aka BCB) and etc).
We used to trigger uncrypt in ShutdownThread before rebooting into
recovery. Now we expose new SystemApi (RecoverySystem.processPackage())
to allow the caller (e.g. GmsCore) to call that upfront before
initiating a reboot. This will reduce the reboot time and get rid of the
progress bar ("processing update package"). However, we need to reserve
the functionality in ShutdownThread to optionally call uncrypt if
finding that's still needed.
In order to support the update-on-boot feature, we also add new
SystemApis scheduleUpdateOnBoot() and cancelScheduledUpdate() into
android.os.RecoverySystem. They allow the caller (e.g. GmsCore) to
schedule / cancel an update by setting up the BCB, which will be read by
the bootloader and the recovery image. With the new SystemApis, an
update package can be processed (uncrypt'd) in the background and
scheduled to be installed at the next boot.
Bug: 26830925
Change-Id: Ic606fcf5b31c54ce54f0ab12c1768fef0fa64560
This partially reverts the previous commit [1], which allowed special
components to be granted some pre-configured default permissions.
With this CL, we no longer grant Contacts permissions to pre-installed
IMEs. Rationals are:
1. Even without this CL, not the all pre-installed IMEs are granted
Contacts permission by default, because it was done during the boot
time where InputMethodManagerService is not yet completely
initialized. The current behavior is confusing not only for users
but also for developers.
2. In almost all the cases, IMEs are supposed to be able to work
without Contacts permission. Hence it is not too late to ask users
to grant the permission to the IME after the initial setup is
completed.
3. It is difficult to add new features such as File-Based Encryption
(FBE) with keeping the current implementation, because currently we
dynamically call mSettings.setCurrentUserId(userId) just to
enumerate what IMEs will be enabled for a given user. Adding
another condition (whether the user has already unlocked the device
or not) would make things more complicated.
Note that LatinIME has already support the case where Contacts
permission is not granted by default. It does not ask users for
anything until Setup-Wizard is completed, and requests Contacts
permission only when the user taps a message in the suggestion strip
that suggests users to use contacts name for typing suggestions.
[1] If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9
adc1cf4604
Bug: 24756974
Bug: 26743676
Change-Id: Ief2a40b5971b3eb97d765f934d20ce7f2ef25665
An app can now declare that it really needs to be backed up
whenever possible even if it is currently engaged in foreground-
equivalent work. Only applies to full-data backup clients: key/value
backups are not intrusive on normal lifecycle so they can already
happen in such circumstances.
Bug 26790411
Change-Id: Ia0ebcc7a53da888ae9ae4d63cd4bcab6e3a2e866
Backup requires both CE and DE storage to be available, so delay
spinning up the backup system until the user is unlocked, since
that's when CE storage becomes available. Note that devices without
FBE immediately transition USER_SYSTEM into the unlocked state,
since their CE is always available.
Offer to backup and restore files under both CE and DE. Since DE
is effectively the same as CE, most logic is simply duplicated for
now, but it could be simplified in the future. Since system apps
can force their default storage location to DE, we always build
explicit CE and DE paths.
Add getDataDir() to give clean access to the top-level private data
directory, but disclaim that apps shouldn't create files there.
Bug: 26279618
Change-Id: Ic34a4b330223725db93b1d0f5c9dffc88002c61f
This change makes StorageManager.getVolumesList(),
StorageManager.getPrimaryVolume(), and StorageVolume public and adds a
buildAccessIntent() in the latter to automatically generate the
ACTION_OPEN_EXTERNAL_DIRECTORY intent, but it doesn't change the
ACTION_OPEN_EXTERNAL_DIRECTORY implementation yet (i.e., it still takes an URI with the physical path of the directory, instead of a StorageVolume and
a directorny name).
BUG: 26742218
Change-Id: I36c59c42b6579e125ec7f03c3af141260875a491
Refactor setPackageSuspended into setPackagesSuspended. The rationale
is that the consumers of this API are likely to want to remove
multiple packages at once. Rather than calling the API N times, call
it just once.
The good part is that we already have the broadcast intent for
suspended packages take an array so only one broadcast. Less stress
on the system.
Another good part is that (right now) we only have one consumer of
this API and it will be easy to make changes once this CL goes in.
As a shell command, for consistency only allowed one package at
a time.
Bug: 22776761
Change-Id: Ic8b8cf64d0a288ea3a282bb7b72f9d663b3b0049
Instead of always rebuilding the full ApplicationInfo for a
package when callers are only interested in the suspended status
add a new fast API in Packagemanager (which only checks the
suspended user setting for the requested package and returns
a boolean) and change the appropriate caller code too.
Bug: 26794775
Bug: 22776761
Change-Id: Ide8428ef734479360d5a8a75fd8e0ed8ddf2da7a
We were previously only doing it for SCREEN_ORIENTATION_UNSPECIFIED,
but there are other orientation settings that aren't fixed that we
need to handle.
Change-Id: If21fcd8312b6267407d94b6646158ac6eae44b44
We're starting to see more instances of device features that will
increment separately from the SDK API level, such as camera HAL,
GPU capabilities, Bluetooth, and other hardware standards.
This change adds the ability for device features to specify a
version, which is defined to be backwards compatible. That is, apps
requesting an older version of a feature must continue working on
devices with a newer version of that same feature.
When a version is undefined, we assume the default version "0".
Bug: 27162500
Change-Id: If890bf3f3dbb715e8feb80e7059a0d65618482ea
