b0c8a887299a7f462c41408edda6043202143233 |
|
28-Aug-2017 |
Amith Yamasani <yamasani@google.com> |
Retry crashed bound foreground service with some delay After quick crashes, back-off for 30 minutes and try again. Keep backing-off up to 10 times and then give up. Bug: 63075467 Test: runtest -x frameworks/base/tests/ServiceCrashTest Change-Id: I3819aefac5fd48b49a70b1765e07696f2ad61328
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
94e82d9b0e7ee2e657564e5904b556eeefc1d423 |
|
14-Jul-2017 |
Andrii Kulian <akulian@google.com> |
DO NOT MERGE ActivityView be gone! This hidden functionality is no longer support/needed since we now have multi-window/display. A new view group class will be added later that uses multi-window to support remaining functionality of this class. Test: go/wm-smoke Change-Id: Ie2fa2de92841d33199da9988741905060dd1ddf4
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
66c0d7ce2f28da0d8f2f1685c67133abfc1342df |
|
21-Jun-2017 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Added dumsys activity starter" into oc-dev am: ea0de895bb am: eb75461502 Change-Id: Ib9531c5ead164dbce6d8b3376c9ee3a84841ee4c
|
692dcd64146786ce15c96cf054fb7808dd625667 |
|
20-Jun-2017 |
Wale Ogunwale <ogunwale@google.com> |
Added dumsys activity starter Dumps the last state of ActivityStarter to help debug ANR issue. Also log reason for starting an activity. Bug: 38121026 Test: adb shell dumpsys activity starter Change-Id: Ib77ff974b1122946fac96f8835ab3fdfc732cf7b
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
f013daa3ac7718c983cf850784f5cf29ee027487 |
|
09-May-2017 |
Narayan Kamath <narayan@google.com> |
ActivityManagerService: Add support for new stack dumping scheme. Tombstoned now fully supports java traces and intercepts, and the debuggerd dump API has been extended to support dumps of java traces. This change switches ANR dumping over to using this API when the right system property is set. The new flow is as follows : - The system_server creates a new file using File.createTempFile for each ANR detected by the activity manager. All dumps associated with that ANR go into that file. - All dumps are initiated using debuggerd client API (debuggerd_trigger_dump) which handles all the timeout measurement for us. It can also guarantee that no writes are made to the file after the method returns, so we have no need of inotify watches and other fiddly mechanisms to monitor progress. Also, this would give us the ability to add meta-information about timeouts etc. to the dump file itself, thougt that hasn't been implemented just yet. Test: Manual Bug: 32064548 Change-Id: I37e72c467e6dc29da4347c2a2829eeeeb1ad3490
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
5ddcca789172da68b7505fb301f6dc7cf173b4dc |
|
29-Apr-2017 |
Fyodor Kupolov <fkupolov@google.com> |
Additional log instrumentation for multi-user Log when app crash dialogs are shown: Showing crash dialog for package <package.name> u<user_id> Also log when BOOT_COMPLETED_DELIVERED to all receivers: ActivityManager: Finished processing BOOT_COMPLETED for u<USER_ID> Test: CreateUsersNoAppCrashesTest is passing. New messages are logged. Bug: 37751789 Change-Id: Idef634007e9dd5f957eb6c5e97f40f3e6ac6dd18
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
a22d9fbe8c1cf3cb47db0bfecbd4fd84c59b6ec0 |
|
26-Apr-2017 |
Narayan Kamath <narayan@google.com> |
AppErrors: Refine notion of "interesting" processes for b/g ANRs. - SystemUI is always interesting, regardless of whether it's currently displaying any interesting activities or not. - Any process that hasOverlayUI or hasTopUI is considered interesting. - Any process that hosts an active foreground service is considered interesting. Bug: 36383925 Test: manual Change-Id: I852a00344f913200020c4f80500e38ff101fe05d
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
a52fc49845d1103dea2380f34b96e2a22ea1801e |
|
04-Apr-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Themes: Apply themes to system_server safely" into oc-dev
|
90d1e363ed4956e3454b943407a7ebee9ae6e351 |
|
30-Mar-2017 |
Brian Carlstrom <bdc@google.com> |
Include likely IMEs in ANR dumping Test: Start IME, induce ANR in Settings, verify /data/anr/traces.txt Bug: 36704599 Change-Id: I5e6209ec25754bd27c57c58b27edeee38eb005de
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
a82b62678a0e1eaba50ec5adce93862683dac065 |
|
22-Mar-2017 |
Adam Lesinski <adamlesinski@google.com> |
Themes: Apply themes to system_server safely Creates a new UI Context for UI based operations. This UI Context is wired up the same way a normal app Context would be, and is subject to change when overlays are enabled/disabled. For this reason, only UI should be using this new Context. All other operations should be using the original system Context so that changing themes don't impact the regular operations of system_server. Also added some sanity checks at key places where we show UI (ShutdownThread, BaseErrorDialog). Bug: 36059431 Test: $ adb shell am crash com.android.settings Test: Observe crash and power off dialogs are blue with PixelTheme Change-Id: I87227ee2e0be1e72dcde8f482b37725cb687260b
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
94a0dcdde12192ad0815ec88f8ac62152f6a58b4 |
|
27-Mar-2017 |
Martijn Coenen <maco@google.com> |
Fix nativeProcs being null. dumpStackTraces originally checked this. This only happens when a silent ANR is triggerred on a process name not in NATIVE_STACKS_OF_INTEREST. Bug: 36414311 Bug: 36652737 Test: manual Change-Id: I24402fb2ef2e08482f866dc1086ce83c1365d7ec
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
6b47c54a65d8c0aca9a6523a926a386ecfaec069 |
|
21-Mar-2017 |
Steven Moreland <smoreland@google.com> |
WatchDog: dump hal pids when killing a process. Test: `adb shell am hang --allow-restart` -> Watchdog dumps hal traces (eventually) Bug: 36414311 Change-Id: I5143cedf3e5ab4695d2507a29993e748f6de17d5
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
66524247d4d5f21a86624a6ccdd5f014bf5aa8b6 |
|
11-Mar-2017 |
Brian Carlstrom <bdc@google.com> |
Dump native stack for background ANR if process is of interest Bug: 30112521 Bug: 36043456 Bug: 35241370 Test: make -j32 -k && flashall Change-Id: I25b134ec24c534f3cfeb5a7c43195da3a6285d57
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
340417356d92d0db71d0692344e66886ca795dfd |
|
01-Feb-2017 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #30977956: Enable Instrumentation tests for multi-process apps New android:targetProcess attribute on <instrumentation> allows you to specify the processes the instrumentation will run in. This reworks how instrumentation is run in the activity manager to better formalize its state and semantics, allowing us to keep track of it across multiple processes. This also clearly defines what happens when multiple instrumentations are running at the same time, which is useful for writing CTS tests that test the instrumentation APIs themselves. Adds a couple new APIs to Instrumentation that helps with the new situation where instrumentation can run concurrently in multiple processes. Test: new CTS tests added (textXxxProcessInstrumentation in ActivityManagerTest.java in cts/tests/app/src) Change-Id: I2811e6c75bc98d4856045b2f0a45fb24af5d366f
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
8aa8fe128992f7e47ecbc8588027eaec82012f3a |
|
21-Jan-2017 |
Christopher Tate <ctate@google.com> |
Add an 'am crash' shell command Induce a normal VM crash via adb, because it's quite different from the effects of 'am kill'. Test: induced crashes via adb shell using both pid & pkg Change-Id: I79654afa7c4a70364cfd7d3af3e80a7b0e59b882
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
fe6f85cac9e823fd33a134f7129fdf7310703293 |
|
20-Jan-2017 |
Jeff Sharkey <jsharkey@android.com> |
Introduce RescueParty. When a device gets stuck in a crash loop, it's pretty much unusable and impossible for users to recover from. To help rescue devices from this state, this change introduces a new feature that watches for runtime restart loops and persistent app crash loops, and escalates through a series of increasingly aggressive rescue operations. Currently these rescue levels walk through clearing any experiments in SettingsProvider before finally rebooting and prompting the user to wipe data. Crash loops are detected based on a number of events in a specific window of time. App stats can be stored in memory, but boot stats need to be stored in system properties to be more robust. Start up RecoveryService much earlier during the boot so we can reboot into recovery when needed. Add properties tha push system_server or SystemUI into a crash loops for testing purposes. Test: builds, boots, forced crashing walks through modes Bug: 24872457, 30951331 Change-Id: I6cdd37682973fe18de0f08521e88f70ee7d7728b
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
b8660061435baa2d63036aa5720caaf79a82a9d3 |
|
29-Nov-2016 |
Mark Lu <Mark_Lu@htc.com> |
Merge "[AM] Fix system server may killed when monkey crash." am: 21ed56daac am: ef4267e53a am: e2ccdd9d93 am: fe9e70db6f Change-Id: Ibd65beb3ba4968eac43b2255e8a3ffcb8d6976f9
|
ef4267e53aec6e99fe9b672e94cb20a33dcf20e8 |
|
29-Nov-2016 |
Mark Lu <Mark_Lu@htc.com> |
Merge "[AM] Fix system server may killed when monkey crash." am: 21ed56daac Change-Id: I0a556d253099eab172ac297cb3e799b9095ef853
|
b5e249963141b2ab00d1a9b5e4b76d5689d64f2e |
|
21-Nov-2016 |
Mark Lu <Mark_Lu@htc.com> |
[AM] Fix system server may killed when monkey crash. Symptom: monkey crash caused system server killed. Root Cause: when monkey crash or app crash before process bound, calling AppErrors.crashApplication will first clear binder identities, that will caused calling pid / uid will become with current process (i.e. system server), so in handleAppCrashInActivityController, when monkey registered activityController would like to kill crash process, but not found in AMS (monkey created by app_process) then using calling pid / uid will become to kill system server. Solution: add calling pid / uid parameters for handleAppCrashInActivityController to prevent binder identities cleared case. Test: To simulate monkey or app crash before process bound may not easy by using simple command, but we can write a sample program to simulate RuntimeInit to call handleApplicationCrash when met uncauchtException, Below is test steps in Android 7.1.1 emulator. 1. start emulator 2. after emulater started, use "adb shell am monitor" to set activityController & monitor process by console. 3. write a .jar program as monkey by below sample code to simulate null application binder to call handleApplicationCrash() as RuntimeInit: package com.android.test; import com.android.internal.os.BaseCommand; public class SimulateMonkeyCrash extends BaseCommand { public static void main(String[] args) { IActivityManager am = ActivityManagerNative.getDefault(); try { am.handleApplicationCrash(null, new ApplicationErrorReport.CrashInfo(new Throwable())); } catch (RemoteException e) { e.printStackTrace(); } } 4. write a .sh file named SimulateMonkeyCrash.sh as below: # base=/system export CLASSPATH=$base/framework/SimulateMonkeyCrash.jar exec app_process $base/bin com.android.test.SimulateMonkeyCrash "$@" 5. let .sh file is executable by "chomod 755". 6. push .jar file into /system/framework & .sh file into /system/bin 7 execute .sh file. 8. activityController will detected program crash in console as below, press k: Waiting after crash... available commands: (c)ontinue: show crash dialog (k)ill: immediately kill app (q)uit: finish monitoring 9 you can see system server is crash. Change-Id: Ibac4d88872f24af109d8e8522ecf5ac72fac0ce0
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
383db5ebcc3a4a615faf249bf4f126f42e80b82e |
|
22-Jun-2016 |
Tamas Berghammer <tberghammer@google.com> |
Update package names to work with the proto3 compiler Bug: b/28974522 Change-Id: I5f3adf4946ee4ba1e09e4f40afe83c151405972a
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
8b4da0ee048764d8d893b9857d8948329eb37418 |
|
16-Sep-2016 |
Mark Lu <Mark_Lu@htc.com> |
Merge "[AM] Skip unnessary ANR when process already died." am: 831a4aea1e am: 57341808f1 am: 7aafc81c2e Change-Id: I95c126b223ed99b5bf09d1e3effed018ee950a4b
|
7aafc81c2e07262e77ac5108407403bc4a522f96 |
|
16-Sep-2016 |
Mark Lu <Mark_Lu@htc.com> |
Merge "[AM] Skip unnessary ANR when process already died." am: 831a4aea1e am: 57341808f1 Change-Id: I95e71746ddf33247da1b81c9036b3f46d89f446e
|
41d65f28c202bd405f60f7739fd2cd775bb35213 |
|
23-Mar-2016 |
Mark Lu <Mark_Lu@htc.com> |
[AM] Skip unnessary ANR when process already died. When app process been killed by AMS or lowmemkiller just before ANR report, because process record info has been cleared after received death recipient, it also cannot dump trace log because process already dead, so report ANR & show ANR UI to let user wait seems is unnecessary. (compare normal ANR case, if kill app process by command, ANR dialog will also dismissed, it seems reasonable.) To check above condition, if ANR process record killed set as true, it means process already dead & can skip report this ANR. Change-Id: I483cb02bacb10c32db80ca1097310b02abbac24d
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
a0b404f09dfb73411b51903630cfe8b3003efdab |
|
14-Sep-2016 |
Tobias Lindskog <tobias.lindskog@sonymobile.com> |
Merge "Skip ANR for processes that have been killed" am: 9d9cf5b383 am: b35b5f2bd1 am: f61a27c096 Change-Id: I7c2a7ec65288199584971de895273918af267b7c
|
f61a27c09658a631866326d0787fb56c3c44e129 |
|
14-Sep-2016 |
Tobias Lindskog <tobias.lindskog@sonymobile.com> |
Merge "Skip ANR for processes that have been killed" am: 9d9cf5b383 am: b35b5f2bd1 Change-Id: Iee85d717feac0d7652993d90d4157052dc4292c1
|
9645b0ffda8d328fd563ae9ad611c18a44102930 |
|
12-Sep-2016 |
Wale Ogunwale <ogunwale@google.com> |
Don't try to show crash dialog if lock screen is showing. The crash dialog doesn't show on top of the lock screen so don't try to display the crash dialog in this case so that the process can be killed right way instead of waiting for the user to interact with the crash dialog that isn't visible. Bug: 31395870 Change-Id: Ic1ce9a133ea12cee8a27690004ac3b56cf75808b
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
313177dccacaf5fefd2954d90c065e35e5b03253 |
|
03-Feb-2015 |
Tobias Lindskog <tobias.lindskog@sonymobile.com> |
Skip ANR for processes that have been killed If a controller is attached and decides to kill a process after an ANR, other ANR reports for that app that are queued up won't be handled until after the app has died. This can create a report without the relevant callstacks because the app is dead by the time the traces are dumped. Since the trace file is global, the traces recorded for the first ANR are overwritten, leaving us with no clue as to what happened. After the app has been killedByAm, it is not interesting to handle ANRs for that app until it is started again, so killedByAm can be used to filter out these spurious reports. Change-Id: I34ba790f6d29d563c819dc2f6ac71a3c8955bb76
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
6a7e08920c6c7d88352f66df6ba923b9156feb36 |
|
23-Aug-2016 |
Adrian Roos <roosa@google.com> |
AppErrors: Don't suppress dialogs when ANR_SHOW_BACKGROUND is set Change-Id: Ie6013013ff4e23e51e471e97d15e113cc759657e Fixes: 30929056
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
b2b3b644172d2ea95380108fd0b5c26c4a94b2c0 |
|
05-Aug-2016 |
Erik Wolsheimer <ewol@google.com> |
Add missing null check to AppErrors#handleAppCrashLocked BUG: 30692618 Change-Id: Ibe3589e1248520067714d5a20963a17935789066 (cherry picked from commit dc74142c74bf37e0ddcbe6ec7d76f57191815b44)
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
805ea307e726e31a179a3ac9856b0588450bcc63 |
|
27-Jul-2016 |
Adrian Roos <roosa@google.com> |
Allow restarting foreground services once If a process is important to the user, even if it is not hosting an activity, we'll allow it to be restarted once Change-Id: I3e2997d1ebe87514e8ce71f81698241234487ed8 Fixes: 30250003
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
a7a342742579ca7ff48026907ec8b6313bc97fac |
|
14-Jul-2016 |
Tim Murray <timmurray@google.com> |
Merge \"Don\'t dump stack traces for background ANRs.\" into nyc-dev am: b2b203ae13 Change-Id: I0777b4d28be2601425b6fe7f51f3ec7dc5635c6e
|
f0f9a829818a98236c81b96f9fe0f9ac3125eb1d |
|
13-Jul-2016 |
Tim Murray <timmurray@google.com> |
Don't dump stack traces for background ANRs. Dumping stack traces can be extremely expensive, and doing so for background applications often has extremely negative side effects for foreground applications. This can be exacerbated by resource-intensive applications, because those may exhibit thermal throttling in the first place. For such applications, the additional performance hit caused by stack dumps may be catastrophic. Instead, don't dump stack traces for background ANRs except for the app that actually ANR'd. bug 30112521 Change-Id: I8a05059343254861c436a193690cd1c50a95d674
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
4d8959489d6b4123340dd2113044548b37d1b370 |
|
12-Jul-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #30013670: Phone AP crash when testing VT call Intent categories may be null. Change-Id: Ic2e0438460741b264ddbfe77d2a14973f9af7d95
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
ad028c1616be016e6bef0d9a664d3a0054804e01 |
|
17-May-2016 |
Adrian Roos <roosa@google.com> |
Simplify crash dialog Remove "Reopen app" for background crashes, remove "Close" for foreground crashes. Make crash dialog cancelable with back / tapping outside. Remove reset option for repeating crashes. Change-Id: I3773ee6b6986efa35da30830fec223300cda5d75 Fixes: 28768481 Fixes: 28740658
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
fa3991aae02676d5c619c86adf514def09802d78 |
|
28-Apr-2016 |
Andrii Kulian <akulian@google.com> |
Fix crash loop when activity controller was set If activity controller was set and application crashed - process was killed, but records in task history were not erased and AM restarted crashed activity. This caused crash loop if activity was crashing on every launch. This CL handles app crash correctly in this case + lets AM handle instrumentation test crash in ActivityManagerService#handleAppDiedLocked to remove code duplication. Bug: 28374171 Change-Id: Idf50d1e2cc784c0ae970aa290b82fe1eedd6d1fd
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
5719028766f51512beffa623db7ee682851570a0 |
|
21-Apr-2016 |
Joe Onorato <joeo@google.com> |
If a crash dialog can't be shown, just kill the process. scheduleCrash() calls into the app process to ask it to nicely show the crash dialog. If that call fails, rather than just silently stopping, kill the process right away. It might be out of control. This also adds an additional check for killedByAm to the flow there so if the activity manager already has killed it, the dialog won't be shown. Bug: 28196243 Change-Id: I979f01074e5890640e7b06e29eeb0d6c38803569
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
445fd2afe9336cecf76e41d78aa0b6f3b7053700 |
|
18-Mar-2016 |
Phil Weaver <pweaver@google.com> |
Eliminate deadlock in magnification. Use the lock from AccessibilityManagerService in MagnificationController, since the two services call each other with locks held. Bug: 27725795 Change-Id: Iaed6749bf217210457325c3912da0f7aa0f6319a
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
9369efdf6a43d8fa0f82dcae651c76b85a5ea0ad |
|
03-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #24403813: ANR traces are too heavyweight. Most of the changes here are optional debugging output. The actual functional changes: (1) One of the ANR paths was not being dispatched on the activity manager's handler, so it could execute concurrently with other ANR collection, conflicting with the ANR file. (2) Bumped up the timeout for trace collection from 200ms to 1000ms. This should fix problems where some process were not being included, since once one of the collections times out we can no longer keep synchronized with anything else after and could end up with data getting corrupt or blown away. Change-Id: If6828d2dea1a25cd6d2334a652b1b31654d9062f
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
9046222cb2b1bd57278ddbf71d9f628f8dd254ae |
|
18-Feb-2016 |
Adrian Roos <roosa@google.com> |
Add logging to crash and anr dialog Bug: 26760334 Change-Id: If81c7a6834e86f7390febef6767a07fa4caded4d
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
a85a2c63f191ae8c567ba6845c063cbe3dd750fc |
|
26-Jan-2016 |
Adrian Roos <roosa@google.com> |
Improve ANR dialog Bug: 22692162 Change-Id: Ie1f0ca54216f123ae26df51d42f88b0fa2d65941
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|
20d7df3c3ff0000678a208b25fcf7ddf90c5abe4 |
|
12-Jan-2016 |
Adrian Roos <roosa@google.com> |
Crash dialog improvements, move crash code to AppErrors Factors out the crash and ANR handling code into separate class and allows clearing cache and restarting app from crash dialog. Bug: 22692162 Change-Id: I2a08a4255ea02ab3c7441d351bf278128fcf5a5d
/frameworks/base/services/core/java/com/android/server/am/AppErrors.java
|