95c42974f719d1fac90fc0438eac778e9795681f |
|
02-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
Private flags are masked in correct variable Newly added private flags were being masked in the public flag variable as opposed to the correct privateFlags variable. bug:11033280 bug:11043194 Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
/frameworks/base/services/java/com/android/server/am/StrictModeViolationDialog.java
|
6a591f585909415a1da431a2cc76b7732724037d |
|
02-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
Make room for new public flags Moved two hidden flags to private bug:11033280 Change-Id: Icca867b073aff643eefdaf84df68de86bb6b05ac
/frameworks/base/services/java/com/android/server/am/StrictModeViolationDialog.java
|
be4e6aaa0252dd7da28b7aa85beba982538efa46 |
|
07-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Initial super-primitive process tracker. The goal of this is to keep track of what app processes are doing, to determine who is being abusive, when the system is getting into memory constrained situations, and help the user determine how to resolve this. Right now it doesn't really do any of that, just keeps track of how long every process has been running since boot. Also update the activity manager to use "cached" as the terminology for what it used to interchangeably call hidden and background processes, and switch ProcessMap over to using ArrayMap. Change-Id: I270b0006aab1f38e17b7d9b65728679173c343f2
/frameworks/base/services/java/com/android/server/am/StrictModeViolationDialog.java
|
d4ac8d7b3de27a9f0e4c6af2496ca71d794e42d1 |
|
28-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7211769 and #7244492, thrash around on #7226656. Issue #7211769: Crash dialog from background user has non-working "report" The report button now launches the issue reporter for the correct user. Also for crashes on background users, either disable the report button, or simply don't show the dialog depending on the build config. Issue #7244492: Bugreport button in Quick Settings doesn't actually do anything Now they do. Issue #7226656: second user seeing primary user's apps I haven't had any success at reproducing this. I have tried to tighten up the path where we create the user to ensure nothing could cause the user's applications to be accessed before the user it fully created and thus make them installed... but I can't convince myself that is the actual problem. Also tightened up the user switch code to use forground broadcasts for all of the updates about the switch (since this is really a foreground operation), added a facility to have BOOT_COMPELTED broadcasts not get launched for secondary users and use that on a few key system receivers, fixed some debug output. Change-Id: Iadf8f8e4878a86def2e495e9d0dc40c4fb347021
/frameworks/base/services/java/com/android/server/am/StrictModeViolationDialog.java
|
46d42387464a651268648659e91d022566d4844c |
|
11-Jun-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
More StrictMode work, handling violations in ActivityManagerService. Also starts to do duplicate-suppression. Change-Id: I0502f6ab6c45fa319298de4874ecfe44b7829d21
/frameworks/base/services/java/com/android/server/am/StrictModeViolationDialog.java
|
438d0595121a7a2cdf19741e76e3c0e21a5c173d |
|
10-Jun-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Introduce "StrictMode" This is a new public API for developers to opt-in to strict rules about what they're allowed to do on certain threads. (this is the public face of the @hide dalvik.system.BlockGuard, added recently...) In practice this will be used for developers to opt-in to declaring that they don't want to be allowed to do various operations (such as disk I/O or network operations) on their main UI threads. (these operations are often accidental, or even when they are fast come with a good chance of being slow or very slow in some cases....) Implementation wise, this is just a thread-local integer that has a bitmask of the things that aren't allowed, and more bits for saying what the violation penalty is. The penalties, of which multiple can be chosen, include: * logging * dropbox uploading for analysis/reporting * annoying dialog * full-on crashing These are all only very roughly implemented at this point, but all parts now minimally work end-to-end now, so this is a good checkpoint commit before this gets too large. Future CLs will polish all the above 4 penalties, including checksumming of stacktraces and minimizing penalties for duplicate violations. Change-Id: Icbe61a2e950119519e7364030b10c3c28d243abe
/frameworks/base/services/java/com/android/server/am/StrictModeViolationDialog.java
|