When switching to a newly created user, the user may face this bug when he opens the RecentTask screen.
A possible bug scenario is described as follows:
A user id of a removed user may be recycled when created a new user.
However, mRecentTasks is not correctly controlled so that old information may still remain and be possibly mapped to wrong user.
This patch prevents this bug by explicitly removing old information in mRecentTasks when removing existing user.
Change-Id: I1874dbd604598a5d740ae1e034981e21214c15c6
Signed-off-by: Eunae Kim <eunae.kim@lge.com>
Sympton:
During testing, skip kill native crash process manually because it will continue to die by default.
Root Cause:
Large process may take some time to do coredump.In auto test, crash process will be killed immediately that results incomplete coredump file.
Solution:
If the tester (IActivityController) will handle app crash event,
Do not kill native crashed process if the rom is debuggable.
Change-Id: Ia360af147d694125d440e5ba2f958c4759a50494
Sympton:
Next activity only adds to history but does not launch/resume then results ANR.
Root Cause:
In a rare timing, some windows are switched at the same time,
it will cause some finishing records on the top temporarily,
then set startIt to false that skip to resume the real top activty.
Solution:
If all activities in a task are finishing, do not use it to check.
The behavior/checking is the same concept as in JellyBean:
// If starting in an existing task, find where that is...
boolean startIt = true;
for (int i = NH-1; i >= 0; i--) {
ActivityRecord p = mHistory.get(i);
if (p.finishing) { // <--
continue;
}
Change-Id: I9d81a7b5182400c52e173da23eee61c74692beee
Fixes an issue where the stencil buffer is corrupted
(used in overdraw debugging, path clipping) when used in
conjunction with a HW accelerated WebView.
bug:15023700
bug:16465551
Change-Id: If201b503931380f7107a34e9a9a2f877a50f72b1
If an application that has a broadcast receiver is killed
during broadcasting, thread variable of ProcessRecord becomes null
so that IIntentReceiver#performReceive() is called
in BroadcastQueue#performReceiveLocked(). But if binder driver has not
noticed the death of the application yet, it can't throw
DeadObjectException. After that, binder driver notices. But it can't
notify DeadObjectException to the caller because performReceive() is
async call. So broadcasting keeps on waiting for finishing
performReceive() until timeout.
This change checks the death of the application before calling
performReceive() and skips broadcasting to the receiver
if the application has already died.
Change-Id: Ifa02b8b1a7e7b6fd314de90fedff5b7a5326825d
Symptom:
When switch between two home activities, the home process might not be updated to the correct one. In that case, the home activity might be killed easily.
Root Cause:
The home process is updated only when a home activity is newly created or being restarted. ActivityManager did not update the home process when simply resume a home activity.
Solution:
Update home process when home activity resumed
Reproduce Steps:
1. Install a launcher application, such as Apex Launcher
2. Press home key to change to Apex Launcher by "Just once" option
3. Press home key to switch back to original home activity by "Just once" option.
(The home process is still the Apex Launcher's process because ActivityManager does not update the home process when resuming the original home activity.)
Change-Id: I046279ca7ba851a283ee67ea19202890f7b3f343
The failing scenario is
- install v1
- run
- update to v2
- update to v3
- run
last run was failing with initial multidex library versions because
it's still running on v1 extracted secondary dex files.
(cherry picked from commit 05e2a94c8b510131f43a686f5188d4c0f2a5eebd)
Change-Id: Ibb5d16642b127ee4c0baddc4f6ba461c11d25f90
Symptom:
The root activity not always located at index 0 of the task.
For example, the index 1 activity will become the new root
when the original root activity (at index 0) finished.
The new root activity might be finished unexpectedly before
the original root activity actually destroyed.
Solution:
Check frontOfTask to avoid finishing the root activity unexpectedly
Change-Id: I623ab97e9c95c83b3cfe7c9dfc151a291a391ea4
Symptom:
In certain situations, application starts activity while
it is in background. When an existing background activity
starts a new activity which results to be kept in the same
background task, the new activity won't be resumed.
In that case, the background task (sourceTask) should not be
moved to top in window manager.
Solution:
Move top task of the target stack to top in window manager
Change-Id: Id7a37ea67ce1f80e0c2b5399865c51fd7113deb8
Replace locale.substring(0, 2) with a function that always
returns the first component of the locale (assumed to be the
language).
bug: 10090157
(cherry picked from commit cefc79c6b18bb2e824c299e7b9e212071e5ebc43)
Change-Id: I56b02dd0c6dc222daa3ceade841a30879449bb4a
The logging is LocalTransport.java is enabled by
default.
Change default to false to remove logs, as this class
states that it is only for debug.
Change-Id: Iae63c7b62edbd503c606f0aee671a9579e78843d
Sympton:
When application crash in a special timing and system server's InputMethodManager is binding, deadlock may occur.
Root Cause:
Thread(1): When using InputMethodManager in system server, it will lock mH(handler) of InputMethodManager,
and sometimes it will call to InputMethodManagerService::showCurrentInputLocked and will call bindService at some condition,
then it will also lock ActivityManagerService.
Thread(2): When an application crashed, it will lock ActivityManager when showing crash dialog, inside the dialog,
it will call setEnabled of Button and lock mH of InputMethodManager.setEnable of TextView will lock IMM's handler.
So the deadlock happened as the flow: (2) lock AMS -> (1)lock mH -> (2)wait mH -> (1) wait AMS
Solution:
Reduce nested lock of error dialog: post message to let (2) lock mH after release AMS lock.
Change-Id: Id85c29406236db3b5fca9655fde1fcaf0afd1337
We should call ResourceTable::getLocales directly,
and not AssetManager::getLocales. The latter will convert
"tl" to "fil" so we'll end up thinking we have resources
for "fil" when we don't really have any.
bug: 15873165
Change-Id: I9753e4608aaecede328a40ee1f3ee6b016d0dedc
