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
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
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)
There is the case that adjustSurface() get called even if
the size of the surface of DimLayer is not changed actually.
Since changing the size of a surface is processed synchronously
in the SurfacFlinger, there is usually a few milliseconds delay
(up to 1 vsync interval) when we launch an application.
This patch avoids such cases.
Change-Id: Ib1f76d54f9f2364ac54b70120e4b781e8534e750
Signed-off-by: Dohyun Lee <dohyun.lee@lge.com>
Some UI is displayed (boot/optimizing) before the configuration
has been completely set. This noteably happens for watches and
TVs because UIModeManagerService hasn't started yet.
UIModeManagerService is started earlier, and its dependency
TwilightService is loaded during the "all system services ready"
boot phase.
b/18388692
Change-Id: Iabdf8ac3eb04ebcb44779d752e19042769cc65c6
The original logic would let the app hidden by keyguard be able to
decide the orientation. While going back from a show-when-locked app
to keyguard, there would be a short time that keyguard is unable to
decide the orientation, which causes WMS uses the wrong orientation
from the wrong app.
https://code.google.com/p/android/issues/detail?id=155640
Change-Id: Ibc17bfe4603f68b241dc7380459ec9de42a3e259
Follows the Google's permission check policy.
Add a getLegacyVpnInfoPrivileged method which skips the permission check
and change getLegacyVpnInfo to check the permission and then call getLegacyVpnInfoPrivileged.
It is already checked in this commit : https://android-review.googlesource.com/#/c/141771/
Signed-off-by: SangJin Cha <sj.cha@lge.com>
Change-Id: I83cfaedbd85745574f3ddf118b11b6e0415483c6
OEM unlock enabled bit is not computed in the checksum,
causing OEM Unlocking to be disabled after the second
reboot.
Bug: 19829441
Change-Id: I100bf5d3958b89323ee35b9e97b19c162209fcd7
Kernel will reuse process id, when wrap-around happens,
there may be just after a pid is freed, a new thread/process
uses the pid immediately.
For examples, there may be a process with pid 1234 killed
by lowmemorykiller or itself (app.killed=false).
Before the death recipient enters AMS, a new thread/process
is started with pid 1234, then when appDiedLocked executes,
this new pid 1234 will be killed again.
It is especially easy happens to zygote:
During zygote starting process, it will stop 5 daemons threads.
And restart the 5 threads after fork is called, so it has
larger pid range to hit the resue case.
https://code.google.com/p/android/issues/detail?id=160661
Solution:
If the dead event is from binder, it is not necessary
to call killProcessQuiet again, because it should really
be dead.
Keep no checking for killProcessGroup because zygote does
not have record under /acct/, and also the parameter uid
has restriction that will not kill another application
which reuses the pid.
Change-Id: Iec4a4884ae641c4d036f4d024ce463f7a351a17b
