When an activity stops drawing following a rotation the rotation
screenshot would become stuck on top of all the other windows. The
timeout was being acknowledged but mWindowsFreezingScreen was set to
true which kept stopFreezingDisplayLocked() from dismissing the
screen rotation animation.
By changing mWindowsFreezingScreen from a two state variable to a
three state variable, including a timeout state we allow
stopFreezingDisplayLocked() to continue and dismiss the screen
rotation animtion.
This change also reduces the APP_FREEZING_TIMOEOUT from 5 seconds to
2 seconds.
Bug: 15664090
Change-Id: Ida5aca002a82ec8fe1ea99f0ced814c5c8f01a95
Symptom:
During switching task in same stack, the first result
of getRunningTasks will be the behind stack's top task.
e.g.
App Task X is starting task Y, the first entry may be home.
Root Cause:
TaskRecord's lastActiveTime is updated when pausing
or resuming. When X task launch a new task Y, Y is
on the top of task history, before X complete pause,
Y's lastActiveTime will be 0 because it is a new task.
Then when comparing the front task with other stack,
other stack will be regarded as the newer one.
Solution:
If the stack is focused stack, give the top task with the last time.
Change-Id: I0adc07608e03d333e0120a0dbc52a0fbbbb12f34
When a new package is created, installNewPackageLI does not need to call
dexopt, since it has already been made.
Bug: 19550105
Bug: 20087446
Change-Id: If6b05bea590eea5f95efebb22a67ccd8cdf632c2
Upon crash of com.android.phone process, NetworkFactoryInfo is
not getting removed from HashMap and will get accumulated on
every start of the process.
Change-Id: Iafde28daddfc82728c03208522682b1efc85a121
In some cases it is possible for the AppToken.allAppWindows list to
get out of sync with the list of windows known to WMS if the client
doesn't call Session.remove(Window). This can lead to an NPE when
the animation threads runs and the display for the window has been
removed.
Bug: 19972099
Change-Id: Ifdf9ff2364b96757bba0539394c4a682f64577c9
Some service which has persistent attribute has restarted again and
again after removing users.
but it dies right after launching because it is not valid in owner mode.
This patch will check service's userId whether userId is alive or not.
And then if userId is not alive, then service will bring down.
Change-Id: Id99bf3c651b88e377f1fd6bec8aaad81318d7579
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
record
Symptom:
Unable to launch activity
Root cause:
There are some cases that would start process while pid
assigned or already running. So the previous application
record will be clean up via handleAppDiedLocked(), but it
won't be removed from ActivityManager.mProcessNames since
the process is supposed to be restart later.
However, if the process is started from a background
operation and has named as a bad process, it silently fail
the launch. Then, the process won't ever be request to
start afterward. The process status is app.pid > 0 and
app.thread is null.
The application components are unable to launch since then.
Solution:
Examine bad process before clean up application record
Change-Id: I53dc06e49254094abc06e460c8b8b33f36803601
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
