We now make sure, when scanning post-factory app installs, that we do not
accidentally activate a "leaked" or otherwise superfluous APK tree that the
scan algorithm happens to encounter before the one that we expect a priori
based on the persisted package-installation state. When we find such an
extraneous installation we ignore it in favor of the expected one, similarly
to the policy used when collecting system-bundled packages that have been
updated.
Even if we find an unexpected APK for the package, if the expected one
turns out to be absent we fall back to the existing "we thought this app
was present and now it isn't" logic.
Bug 19602471
Change-Id: I141a93661946176c05d8cf52a123bdf75c8eef74
AES and HmacSHA256 symmetric keys can now be imported into
AndroidKeyStore. These keys cannot yet be used.
Bug: 18088752
Change-Id: Iad2fd49d15ac4c2d676abe1153f5b5f0b6ff496c
- Change the guava version used to match the one included in the SDK.
The test server uses the same. However, the command line build still
uses the guava present at platform/external/guava, which is compiled
with Java 7. Thus, running the tests from inside the IDE can be done
via Java 6.
- Rebuilt the test app classes with Java 6 compatibility.
- Change similarity threshold to prevent differences due to some locale
settings different java versions.
Change-Id: Ic71d43256a8cf6f9df296e63550667a202c7105f
The existing one, being deleted here, did not work properly: it only
updated the file used by libcore and bionic, it did not update the ICU
data.
Most of the installation logic exists in code in libcore/tzdata that is
independent of the server code so that it can be tested.
Bug: 19941636
Change-Id: Id0985f8c5be2f12858ee8bf52acf52bdb2df8741
If setAppVisibility() is called multiple times in a short interval
while the screen is turned off between the calls, the visibility of
the app would be wrong. For example, the user may see the app under
the launcher, not the wallpaper under the launcher.
The flow to the issue:
1. Screen is on.
2. AM calls setAppVisibility() token=App A's token, visible=true
3. Screen is turned off.
4. AM calls setAppVisibility() token=App A's token, visible=false
Note:
a. In 2., WM would put App A into mOpeningApps, and tell it to be
visible.
b. In 4., because the screen is off now, App A would not be removed
from mOpeningApps. App A might be told to be invisible directly
through setTokenVisibilityLocked(), but it would be told to be
visible again in handleAppTransitionReadyLocked() later.
Change-Id: Icf3d69031ea2822245008248ec8f12bd57218880
Symptom:
The first step of cleaning up application services is
to clear the app state from services (which set sr.app
to null). Then it clean up the service connections.
In some scenario, the Service might be removed during
the connection cleanup (i.e. the Service is no longer
needed). In that case, the Service will be removed from
ServiceMap, but won't be removed from r.app.services in
bringDownServiceLocked(line 1670) because the r.app is null.
Solution:
Remove the service connection first.
Change-Id: I644d73af58fe0e7c1c4a6c9779fe6b5d747b880d
Larger OTAs (750 MB tested) are taking 3-4 minutes
to write, due to the O_SYNC needed to ensure that
the data is actually committed to disk prior to
reboot.
Bug: 18750317
Change-Id: Idfab3ffd0276df4548f69a09c72ad6f4a344b6e6
(cherry picked from commit 01c06dfb076b71cb72c4bff9175bec9d59d2efde)
Ensures that the playback device turns on display output signal
upon receiving CEC command <User Control Pressed>.
Bug: 19518981
Change-Id: I4f898380c9ffc071da2357a51e61309ae5d233f5
(cherry picked from commit 9b8507c52ae845c8eed9fd9952bf66538934b8fd)
