When there is a process died, only resume top if
it contains visible activity.
This can fix case 1 in
https://android-review.googlesource.com/#/c/120901/
Change-Id: I45584e76f9e863980d04bbb593d7d26a8900acd0
Window Manager Service would fail to report window-resized to the
process which has become zombie. This would cause the window to
freeze screen continuously. In this case, we assume the process has
died and remove its window to recycle resources and to prevent it from
freezing the screen.
Change-Id: Ic7384731bf9a1fa8b9602d4f1dbee7492db126c5
Root Cause:
There is a defect in current ProcessStats design
and following is the scenario:
1. Process A is started due to activity with
name of A
2. Process A creates ProessState with application
uid of A
3. Process B is started due to isolated service
declared in application A with name of A
4. Process B uses ProcessState of Process A as
it uses same application uid of A
5. Process B is finished and it leads to
ProcessState marked as dead
6. Process A still keeps using the invalid
ProcessState in dead state
7. IndexOutOfBoundsException is triggered when
system tries to update process state of Process A
Resolution:
use process uid to replace application uid for
getProcessStatLocked.
Change-Id: I881ad9fc492c9e1a892c9e957180cebcfef8352d
Signed-off-by: Ronnie Leng <ronnie.leng@gmail.com>
Symptom:
Report ANR on wrong activity.
Reproduce steps:
(All launchMode, taskAffinity are default and
without additional intent flag)
Case 1:
1.Launch activity A from launcher.
2.Activity A starts B activity.
3.Press home key.
4.Launch activity A from launcher (B is top).
5.Press back key twice to finish B and A,
A sleep 10s in onResume.
6.ANR will report on launcher.
Case 2:
1.Launch activity A from launcher.
2.Press home key.
3.Kill process of A.
4.Launch activity A from launcher.
5.A sleep 10s in onResume, press back key immediately.
6.ANR will report on launcher.
Possible root cause:
Focused activity will not be updated every time when activity
resumed. (the condition to call setFocusedActivityLocked)
Case 1:
Launcher was stopped and not waitingVisible due to launcher
is not the previous one, then getWaitingHistoryRecordLocked
has no chance to correct the real ANR activity.
Case 2:
Due to process of next activity is died, bring existed
task will not set mResumedActivity (it will be set when its
process is started), so when assigning waitingVisible from
processStoppingActivitiesLocked, the return value of
allResumedActivitiesVisible will be true even there is no
mResumedActivity. That results set waitingVisible to false
to previous activity (e.g. launcher), then also cannot
correct ANR target as case 1.
Change-Id: I0b24f46a8fab266382ebc6e2ed84ebeca9358768
Symptom:
System server crash.
Root Cause:
The value curProcState for array index is -1 if the process
has not attached yet.
Solution:
Skip computing for process which is not attached or curProcState
is nonexistent state.
Change-Id: I71aaf45bb78d73097ebe9dfebf76b72f2d243232
In installPackageLI, dexopt is now performed on a staging directory of the app
(dexopt phase 1). For each codepath:
- /oat/<isa> directory is created
- dexopt output goes to the newly created directory. Optimized files have
.odex extension.
Bug: 19550105
Change-Id: Iec59790d97837b78af82b079fd1970de3388c91d
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
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>
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
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
logd reads /data/system/packages.xml (because it also contains
shared UIDs) and is sensitive to line break and tag name issues.
Bug: 19608965
Change-Id: I2a4a6bcfb10529e4b29c9664cbbf12842e689dd1
performDexOptLibsLI and related methods were extracted to PackageDexOptimizer
class. Minor refactoring of PackageManagerService.
This is a non-functional change. It should simplify further work to allow
storing OAT files inside package dir.
(cherry picked from commit eeea67b8c3678d882d3774edc41242c63daa60fa)
Change-Id: I3494a2da70605362bb6fb4625ffbee1cbe1cd457
Assume task T has an activity X lives in process P.
When P is died and before death recipient being called,
start activity with flag RESET_TASK_IF_NEEDED to bring the
existed task T.
Then scheduleResumeActivity IPC will fail and trigger start
a new process that removes task T.
That results resetTaskIfNeededLocked cannot find the task
when continuing the start flow.
Detail:
https://code.google.com/p/android/issues/detail?id=159558
Change-Id: Icc400c7a6c481a3f78657e9fb83cf0c3a17dde68
If the opening app has wallpaper, when the closing app starts hiding,
the wallpaper would be revealed. It would be nice if we play the app
transitions while opening apps, closing apps, and visible wallpapers
are all drawn.
https://code.google.com/p/android/issues/detail?id=150811
Change-Id: I3c7d140f6f6e43e18119e48f9cab441ee96b17e5
When the screen rotation is changing, we will freeze the display
until all the window surfaces are all drawn (this is not including
windows which have no surface). If the opening app's window surface
is created after we stop freezing the display, there would be no
waiting for the app, and the user would see the black screen.
In this change, we would not only wait for the windows which have
surface, but also wait for the windows about to have surface before
stopping freezing display.
https://code.google.com/p/android/issues/detail?id=150921
Change-Id: I7de4db8ca902236f3e9f730b04dbde681cf8c032
In KeySetManagerService, use ArraySet more explicitly. Avoid for-each
loops.
Collections API methods on ArraySet are not very efficient. Iterators
incur two object allocations: a helper and the actual iterator object.
During boot, about 4.5K such calls are made. Using the ArraySet more
explicitly like an ArrayList/array avoids the overhead.
Bug: 19617481
Change-Id: I25df334fa1d4be3210667fb1404e3c43f2585049
Symptom:
Report broadcast ANR on a dead process.
Detail and sample:
http://code.google.com/p/android/issues/detail?id=158329
Root cause:
app.curReceiver can only remember the last running.
If an application is both receiving FG and BG broadcast,
only one of queue can discard, the remain one will still
count as timeout.
Solution:
Select the skip-tartget-receiver by comparing the skipping app
to the first record of mOrderedBroadcasts of each broadcast queues.
Change-Id: Ic68d56f21b417a34f2d30d64ecfbed09c5e1764d
The current SELinuxPolicyInstallReceiver logic can yield a partial
or mixed (old and new) set of policy files under /data/security/current
if there is an error or a crash at certain points before completing
the installation of the update.
Rewrite the logic to avoid the possibility of such partial or mixed
policy updates by using rename on the entire directory of policy
files rather than operating on a per-file basis. Also separate
the extraction of the policy files from the bundle into their own
temporary directory. Make sure we delete any previous temporary directory
or backup directory before using them for this update. Drop the
use of a symlink for /data/security/current altogether; it provides
no benefit.
Change-Id: I564af01c2c3ca1531c216013b8724c7511f32de8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
AM would set the exiting app to be invisible twice by calling
setAppVisibility(). If the screen is turned off during these calls,
the window surfaces of this exiting app won't be destroyed.
The flow:
1. Screen is on
2. App A is finished
3. AM calls setAppVisibility() token=App A, visible=false
4. WM sets a dummy animation to App A
5. WM marks App A's wtoken.inPendingTransaction=true
6. Screen is turned off
7. AM calls setAppVisibility() token=App A, visible=false
8. WM calls setTokenVisibilityLocked() directly (screen is off)
9. WM sends app visibility to App A's client (ViewRootImpl)
10. WM clears the dummy animation from App A
11. App A's client calls WMS.relayoutWindow() to be not visible
12. WM sets App A's window mExiting=true but not destroy its surface
13. App A's window surface leaks...
Note:
a. The call in 3. is from ActivityStack.finishActivityLocked
b. The call in 7. is from ActivityStack.resumeTopActivityInnerLocked
c. In 10., App A won't get the real animation while screen is off
d. In 12., App A's inPendingTransaction=true; WM takes it's animating
e. mExiting won't be cleared because App A has no animation to
trigger WindowStateAnimator.finishExit()
After applying this patch, WM would destroy the surface in 12. of the
above flow.
Change-Id: I18b79ba96695ec80d57a85dc15cf92a9e7d3a6ef
