prepareAppDataAfterInstallInternal may call into ActivityManager which will
try to obtain a lock in a reversed order, which causes a deadlock.
Bug: 27336728
Change-Id: I91bb74cd06c6aa6cee057bab5972b0275d12125b
Initially a surface is hidden after creating, so reflect that fact
in mHiddenForOtherReasons, so it doesn't get shown before the correct
transformation is applied.
Bug: 27350530
Change-Id: Idfe8723195dd1488894da066fafee1f2c2afc12d
The main app window will never finish drawing at this point so there
is nothing to trigger the removal of the starting window.
Also, set ActivityRecord.mStartingWindowShown to true for some cases
where we were telling WM to show starting window but not setting the
flag that would later be used for clean-up.
Bug: 26659857
Change-Id: I7a8582521853f1f95b77d8b08f4dd0cf778f8cbf
Internally isReadyToBeExecutedLocked() needs to check if the target
service is actually present and runnable. For example, when an FBE
device is locked, we need to keep any encryption-unaware jobs
pending until the device is later unlocked.
Bug: 26279465
Change-Id: I53ff4a2243ebe8a199d0e8dcf87dc3f5b06a2686
Since which WebView implementation we use depends on whether the
different webview packages are enabled or disabled we should listen to
changes to the enabled-state of our webview packages (to keep the
webview implementation up to date).
Bug: 27340150
Change-Id: Ie384a48424c9138150ddcc9f7bfaf7b82a911f16
When a device is booting up in an encrypted state WebView won't find the
packages needed for loading WebView and might thus try to use incorrect
webview packages. This in itself might cause us to incorrectly change
the webview provider setting but also causes us to crash the system
server if we try to enabled/disable a package that cannot be seen by the
package manager.
Bug: 27353062
Change-Id: I9349778506e8bec1c56b9b786fe4ed15c7c3260d
Because there is a high risk of making the system instable.
Bug: 22776761
Bug: 26949256
Bug: 26949428
Bug: 26683041
Change-Id: I73b3f05c13b5023db5176e709320ca6e2e5f6354
am: b3fdffbb48
* commit 'b3fdffbb48ecc67054e69ee768917bfc4a1a178e':
Use LocaleList for implicitly enabled subtypes.
Add a utility method to filter locales.
Mechanical refactoring in InputMethodUtilsTest.
There are two major changes in this CL:
1. Now IMMS resets its internal state whenever the system locale list
is changed, rather than just checking the primary system locale.
2. For software keyboard subtypes,
InputMethodUtils#getImplicitlyApplicableSubtypesLocked() now takes
the entire system locale list into account when determining what
subtypes should be enabled by default when the user does not
explicitly enable one or more subtypes.
Bug: 27129703
Change-Id: Iaf179d60c12b9a98b4f097e2449471c4184e049b
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
