| 8231146d4ede7f0c0767da2bfdea58745611417c |
|
03-Apr-2017 |
Jeff Sharkey <jsharkey@android.com> |
Lower-level user enumeration; fix disabled bug.
UserManager may not have been started yet, so discover users by
looking at filesystem.
Fix disabled bug where default should be "false."
Test: builds, boots
Bug: 36794413
Change-Id: If91fd27b955175072228a93aab4b8ac3b27df0bf
/frameworks/base/services/core/java/com/android/server/RescueParty.java
|
| bc9caa1a2a38e23f7a6b61bcda81b5759e45ec66 |
|
12-Mar-2017 |
Jeff Sharkey <jsharkey@android.com> |
Switch RescueParty to PMS.logCriticalInfo().
When RescueParty is triggered, we could end up in recovery before a
bugreport can be taken. To help understand why RescueParty was
triggered after the fact, this change switches a handful of critical
log messages to use PMS.logCriticalInfo().
These logs then go into our persistent log on disk, which is also
included in all future bugreports.
Bug: 35805331, 36033178
Test: builds, boots, forced crashing recorded in persistent log
Change-Id: Ic71206b25c4b0b703e464ff1d07c5e0b31549257
/frameworks/base/services/core/java/com/android/server/RescueParty.java
|
| 1bec44836ed6b29e128849b7be34dc7b2a214e76 |
|
23-Feb-2017 |
Jeff Sharkey <jsharkey@android.com> |
Take another pass at detecting USB connections.
For some odd reason, devices with ADB connections in test harnesses
are reporting that they're connected over an AC charger instead of
USB charger.
So switch to reading a sysfs file to detect an active USB connection.
Test: builds, boots, rescue disabled when USB connection present
Bug: 34872406
Change-Id: I4c2cb9ed7e51b9692ce81eb0ef4945dae0036212
/frameworks/base/services/core/java/com/android/server/RescueParty.java
|
| d9574c7bbf23ca282b93b1297e936a3d2e98e78a |
|
20-Feb-2017 |
Jeff Sharkey <jsharkey@android.com> |
Suppress RescueParty when active USB connection.
When there is a very early system server runtime restart, we may not
yet have a published BatteryManagerInternal, so we need to go directly
to the "batteryproperties" native service to detect the USB state.
Test: builds, rescue is suppressed when USB is connected
Bug: 34872406
Change-Id: I949984cb95495c77de85ac322075177cff07b8b6
/frameworks/base/services/core/java/com/android/server/RescueParty.java
|
| 5fb405ba60dc6daca54d507909b68b5ad8144920 |
|
27-Jan-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Ensure settings provider joins the rescue party
The settings provider has logic to incrementally reset state
in an effort to recover from pushing a bad value putting the
system in a bad state. The settings provider was not force
persisting its state after a reset so after the reboot we
lost the reset changes. Also while resetting we were also
resetting the package name leading to a promotion of the reset
value to being set by the system. Updated the tests and while at
this added logic to synchronously persist critical settings
such as device provisioned.
Test: All tests pass. Manually tested end-to-end rescue party
bug:34677175
Change-Id: Ib240072df2fa549dae39c301008adf48cdf1573a
/frameworks/base/services/core/java/com/android/server/RescueParty.java
|
| cdee83a6147bf1601424d5451c30f0dfb8d0e2a6 |
|
26-Jan-2017 |
Jeff Sharkey <jsharkey@android.com> |
Disable RescueParty in debug/lab environments.
We need to strike a balance between rescuing devices of real users
in the field, while also not interfering with debugging or testing
use-cases.
This change uses "charging via USB" as a signal that the device is
under active development, or is in a lab environment. We could try
checking for an adb connection, but UsbDebuggingManager isn't
started until much later in the boot, so BatteryManager is our best
chance of detecting this case.
Note that we continue to always recover "user" builds, and we never
recover "eng" builds.
Test: builds, boots, skips when plugged in over USB
Bug: 34722552
Change-Id: Ib095482a2ed84e8c5dfb3c71d5f9b88457c2b5e6
/frameworks/base/services/core/java/com/android/server/RescueParty.java
|
| 8773a8d0be66aca6cef6706d0ae9bd72054d72ba |
|
25-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Make SettingsProvider reset no-op for now."
|
| d67ab923fb05201b0e7068a0a9fad164541da609 |
|
24-Jan-2017 |
Jeff Sharkey <jsharkey@android.com> |
Make SettingsProvider reset no-op for now.
Something is funky with how settings are being reset, so disable it
for now. We still eventually offer to reboot and wipe data.
Test: builds, boots
Bug: 34677175
Change-Id: Ied943a04d2a4bab8e5c77e622c56ebf6d4181393
/frameworks/base/services/core/java/com/android/server/RescueParty.java
|
| 9f1fc2d78743ce2d4de546c80d4f93c2ffcc8804 |
|
24-Jan-2017 |
Jeff Sharkey <jsharkey@android.com> |
Disable RescueParty on -eng builds, or with flag.
For development devices, RescueParty can be a little too helpful, so
offer a way to disable it.
Test: builds, boots
Bug: 34669556
Change-Id: I401e8e7a99bdde6c0fe09880f0190384b4b0a3de
/frameworks/base/services/core/java/com/android/server/RescueParty.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/RescueParty.java
|