The flag is used to enforce --interpret-only flag when running dex2oat.
Bug: 12457423
(cherry picked from commit 11e08c010a42390803b65eaa698ca0e768aed896)
Change-Id: I215339527e998b24e274c8df42a5024839e6a9fa
This reverts commit 5073145f85c8197ec4387d5e2599442a7291ca9c.
I spoke to Dianne and she said that if this is making a problem go away then it is only hiding it and there is a deeper problem we need to fix.
I think if killedByApp is true then we should set app and app.thread to null. I'll look at it further when I have more time.
Change-Id: I44c29e15ca654666440472eab2d2af1c5af80b9a
Symptom: No activity was started for startActivity, low repro rate.
Root Cause: Starting activity on a process which was killed by ActivityManagerService.killUnneededProcessLocked() and before receiving AppDeathRecipient of it.
Solution: Choose the flow of starting a new process if ProcessRecord.killedByAm is true.
Change-Id: Ida2639b0fb4631222fc92d65aadc9fd2da637b45
This complements https://android-review.googlesource.com/#/c/103231/
where the instruction set was mapped just for comptilation. The same
should have been done for move,remove and getSize.
The list of dex code ISAs is alo de-duped.
Bug: 16185267
Change-Id: I8fe453a800812e382e8f41b5f7922997aa9c18a9
In the presence of a native bridge it is more efficient to compile the
dex directly to the native ISA than to use the shared library ISA as a
reference.
This can be achieve by configuring the readonly system properties to map
between the .so ISA and the desired dex code .ISA (e.g.
ro.dalvik.vm.isa.ISA1=ISA2).
Bug: 16185267
Change-Id: I50baa7b37e1465b9adf72d6f6b96f526a08d59c7
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
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
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
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
Root Cause:
When there is only home activity existed,
updating home apk will call forceStopPackageLocked to finish the activity.
Then activity history becomes empty, then home will be launched,
but its package is still target to close that results a loop.
Solution:
If home activity has been force-stopped, do not stop the same home activity again.
Change-Id: Icff12028d407873c2e6f50a06bcad231b908ccbd
Root Cause:
Use removeTask with flag ActivityManager.REMOVE_TASK_KILL_PROCESS will set waitingToKill = "remove task"
to the target process when its setSchedGroup is not BG_NONINTERACTIVE.
Later the target process may be killed when applying oom-adj due to setSchedGroup has changed to BG_NONINTERACTIVE.
If the process is needed to restart, the process record will be resued.
Then the restarted process may be killed again because its waitingToKill is not null.
Solution:
Clean waitingToKill when process is dead.
Change-Id: I5ffb5388127f4221da4c700d3f1c224f7ca6e7b2
Symptom: Unable to kill by Am again and will be skipped updating its oom adj.
Root Cause:
A restarted process will reuse original process record.
The flag killedByAm will keep previous state.
Solution:
Reset the flag killedByAm to false when the process is started.
Note: Found another similiar patch If95137d91939cc44882ad2813131bcde0edd0c1b
Change-Id: I59a86648ca8d0aed4c489d92751af120aae5ef90
Prior support forced all third party apps
to be resolved against the default stanza
of the mac_permissions.xml file when assigning
seinfo labels. This meant that all third party
apps, in effect, were untrusted regardless of
cert and therefore received the same selinux domain.
This also had the unfortunate side effect of forcing
certain third party apps into the wrong domains
because of shared userid requests among apps.
This patch removes that restriction and instead
allows all apps, regardless of location, to be
matched against the full mac_permissions.xml
policy file. This then allows all apps signed
with known good certs to receive the same selinux
domains of other apps with whom they share trust.
Change-Id: Iba569c046135c0e81140faf6296c5da26a243037
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
There was lax / incomplete error checking around the
construction of Apk handles. This change changes the ApkHandle
API and makes it throw IOException if the zipfile couldn't
be opened.
Additionally :
- Fix a resource leak in DefaultContainerService
- Report errors correctly during package moves.
bug: 15563874
Change-Id: Ic71a10709eb82b8f53405bbfb2320e80aa96b771
Add getTetheredDhcpRanges() interface and call it before calling
mNwService.startTethering() to update dhcp ranges. This will allow p2p app
to run well concurrently with other tethering app(e.g. usb tethering).
Change-Id: I5e8ffeb5d2d396f48b897cd9396f133e25ecca57
Signed-off-by: Jianzheng Zhou <jianzheng.zhou@freescale.com>
If all activities of a given stack were finishing, no activity was
marked as front-of-task. This confused ActivityManager, so make sure
there's always exactly one activity marked as front-of-task.
Change-Id: I087cbe10280d4a60aa5ccfaefe24a223523fb3f2
We don't want directories like profiles and the former
profile-cache from being included in the prune. SELinux would
have prevented the move, but that's very brittle.
bug: 15677279
Change-Id: I2ff5db056757ffacaf108bb07b02dc0cac7172dd
The presence of ".bc" files in an APK implies
incompatibility with any of the 64 bit ABIs.
bug: 14900093
Change-Id: I66ca339a9a149cb3b7e7b349033d80acdeb4140a
This allows callers to force an install to a particular
ABI. This is intended only for testing (and CTS) and is
not meant for usage by the installer package.
Change-Id: Icb1528c0cd35b1aa9323386cb35ff4aaba374fcb
