| ca8c1051eda15b63ac414c6fe643fd7a71a57d39 |
|
20-Jun-2017 |
Mathieu Chartier <mathieuc@google.com> |
Disable activity leak detection by default for userdebug
Causes too many GCs and related slowdowns.
Verified that assistant launch from holding down home button is now
faster than N.
Test: make and flash
Bug: 62769566
Change-Id: Ib0c1f7a45831b241d3376d1e56db3c6937913b1b
/frameworks/base/core/java/android/os/StrictMode.java
|
| c985ffd5e93465cf69e09d4af1a18ef12c84edce |
|
24-May-2017 |
Jeff Sharkey <jsharkey@android.com> |
Offer listener to observe StrictMode violations.
Primarily used by tests to be more robust, since reading raw logcat
data recently became very flaky.
Bug: 37915178
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest
Change-Id: I3f12508bb6206c53005356b5d8d9ba57aac2436e
/frameworks/base/core/java/android/os/StrictMode.java
|
| f5299f1b88e661ea9c297dc087178d7e82ea7f23 |
|
17-Mar-2017 |
Jeff Sharkey <jsharkey@android.com> |
Disable large-ish parcel logging.
This logging was originally added to track down very large log
messages that were causing Binder transactions to fail. We fixed
a handful of bugs that could have been causing this over in 32575987,
so this logging should no longer be needed in live builds. (In fact,
this logging is being triggered often enough to push other important
debugging information out of logs.)
Test: builds, boots
Bug: 36372780
Change-Id: I640192fbec35693673a2f22b7a82ce54f27937da
/frameworks/base/core/java/android/os/StrictMode.java
|
| 2fa62c5c6414c91c46c6a7085e6e7ac1b782a81b |
|
02-Mar-2017 |
Shubham Ajmera <shubhamajmera@google.com> |
Merge "Fix Javadoc for StrictMode#permitUnbufferdIo" am: b8648ae07a am: c847aae2cf
am: 6404cc18bf
Change-Id: I92ee23cc68a6a204f0cb936c6242475a49a27145
|
| c847aae2cfb524002f9ae3a8e329d38d6fd84e53 |
|
02-Mar-2017 |
Shubham Ajmera <shubhamajmera@google.com> |
Merge "Fix Javadoc for StrictMode#permitUnbufferdIo"
am: b8648ae07a
Change-Id: I86adc3e40c083c999b717384ae38e437a17a9557
|
| ade21170a7d0b623d23b426403790dca3d564a6e |
|
01-Mar-2017 |
Shubham Ajmera <shubhamajmera@google.com> |
Fix Javadoc for StrictMode#permitUnbufferdIo
Bug: 35813076
Test: no tests
Change-Id: I2f71cad7a7a3f85908b322e2b83ba265c49adbad
/frameworks/base/core/java/android/os/StrictMode.java
|
| 0b558701d8eeab870a8f12865e5dd6514868eafc |
|
27-Jan-2017 |
Jeff Sharkey <jsharkey@android.com> |
StrictMode detectAll() based on target API level.
Some apps are asking StrictMode to detectAll(), but we should only
trigger the violation types that they would expect based on their
target SDK level. (This prevents us from starting to yell about
violations in new API levels that a developer never would have known
about.)
Test: builds, boots, older apps aren't triggered
Bug: 34735225
Change-Id: Idff1bfdf57c635b828236e34a24d55350b9fa556
/frameworks/base/core/java/android/os/StrictMode.java
|
| 619a511d4f5b5cc74b9a8ab853db386489e02e6f |
|
19-Jan-2017 |
Jeff Sharkey <jsharkey@android.com> |
StrictMode to detect untagged network traffic.
Network usage is tracked by the kernel at the UID level, which is
granular enough for normal apps, but large components (such as the
system server) are impossible to debug without adding additional
socket tagging to help identify subsystems within a UID.
To help ensure that system components tag all their network traffic,
this change offers a new StrictMode option to detect and report
untagged sockets.
Test: builds, boots, all common traffic tagged
Bug: 30943431, 30414041
Change-Id: I825c7941076054732264690247de2863342638e2
/frameworks/base/core/java/android/os/StrictMode.java
|
| f361f2fc89d1724be854a9e0ea2fb5d3930e9a8d |
|
21-Dec-2016 |
Jeff Sharkey <jsharkey@android.com> |
Finish up API for missing content:// flags.
Feature is already built under the hood, but it needs it's own public
StrictMode API so it can be independently enabled.
Test: builds, boots
Bug: 32447617
Change-Id: I3c0c6d62dd36aaf25f30e0ef8e0e7b40cf32c6d2
/frameworks/base/core/java/android/os/StrictMode.java
|
| 1804995d7ef7c76966824307b48e7eddbddbfce5 |
|
07-Dec-2016 |
Jeff Sharkey <jsharkey@android.com> |
Fix two StrictMode stack collection bugs.
am: 20db11cfda
Change-Id: Ie68764c9864e1c26f43c9d70c5697fe12d00e665
|
| 20db11cfdab0e2838308847e644d9e6d4c31079b |
|
07-Dec-2016 |
Jeff Sharkey <jsharkey@android.com> |
Fix two StrictMode stack collection bugs.
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
(cherry-picked from commit 58f27b5033542150a78fb050e2f85253a48efa67)
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
/frameworks/base/core/java/android/os/StrictMode.java
|
| 58f27b5033542150a78fb050e2f85253a48efa67 |
|
07-Dec-2016 |
Jeff Sharkey <jsharkey@android.com> |
Fix two StrictMode stack collection bugs.
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
/frameworks/base/core/java/android/os/StrictMode.java
|
| fb833f38a0c9a27b55784f2bf3dcd7aa7d652157 |
|
01-Dec-2016 |
Jeff Sharkey <jsharkey@android.com> |
Detect content:// leaving apps without grants.
Developers regularly put content:// Uris into Intents, but they can
easily forget to add FLAG_GRANT_READ_URI_PERMISSION to actually
extend a permission grant to the receiving app.
Also fix NPE when path is missing.
Test: builds, boots, common actions work without triggering
Bug: 32447617, 31900890
Change-Id: Ic6054b1d73de50967cf7fe66abc293c60a41b97e
/frameworks/base/core/java/android/os/StrictMode.java
|
| dc589ac82b5fe2063f4cfd94c8ae26d43d5420a0 |
|
11-Nov-2016 |
Sudheer Shanka <sudheersai@google.com> |
Update usage of ActivityManagerNative.
- Remove references to ActivityManagerProxy.
- Add isSystemReady to ActivityManager.
Bug: 30977067
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts
adb shell am instrument -e class com.android.server.am.ActivityManagerTest,com.android.server.am.TaskStackChangedListenerTest \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I07390b6124fb1515821f5c0b37baf6ae74adc8fa
/frameworks/base/core/java/android/os/StrictMode.java
|
| fc46e9b643881b7b2ab76854f3a0ac077e9def8d |
|
22-Oct-2016 |
Sudheer Shanka <sudheersai@google.com> |
Move IActivityManager to aidl.
Bug: 30977067
Test: Existing tests are passing, dump commands still working.
Change-Id: I9cf81c4d381ebce14a6c701e409cbb269f2ff1fb
/frameworks/base/core/java/android/os/StrictMode.java
|
| c95b2c85f3101e686c08d0f0e117088a524894c7 |
|
29-Sep-2016 |
Shubham Ajmera <shubhamajmera@google.com> |
Add new StrictMode thread policy - DETECT_UNBUFFERED_IO
This will enable the developers to check if they could replace an unbuffered
I/O operation with a corresponding buffered I/O operation.
The policy can be set as follow:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectUnbufferedIO().build());
Test: vogar BlockGuardTest
Bug: 3018772
Change-Id: Ib804a8e9980ae40abfd216f8b87c250fd413bd5c
(cherry picked from commit 9b7184a8fd6c940872f1526667dd7933db4bdd5f)w
/frameworks/base/core/java/android/os/StrictMode.java
|
| 9b7184a8fd6c940872f1526667dd7933db4bdd5f |
|
28-Jun-2016 |
Shubham Ajmera <shubhamajmera@google.com> |
Add new StrictMode thread policy - DETECT_UNBUFFERED_IO
This will enable the developers to check if they could replace an unbuffered
I/O operation with a corresponding buffered I/O operation.
The policy can be set as follow:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectUnbufferedIO().build());
Bug: 3018772
Change-Id: Ib804a8e9980ae40abfd216f8b87c250fd413bd5c
/frameworks/base/core/java/android/os/StrictMode.java
|
| a09b4d2a611a7606e8fc8c73a24bd941b6fc173f |
|
15-Apr-2016 |
Narayan Kamath <narayan@google.com> |
Remove unnecessary allocation+unboxing of objects.
Transforming String->int can be done with 0 allocations
using Integer.parseInt.
bug: 28078871
Change-Id: I8d9f322d7154728849dde61ef282046032858d60
/frameworks/base/core/java/android/os/StrictMode.java
|
| f8880561e67e1da246970b49b14285efd4164ab1 |
|
26-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
When system server goes down, crash apps more.
Similar to first patch, but now using new "rethrowFromSystemServer()"
method which internally translates DeadObjectException into
DeadSystemException. New logic over in Log.printlns() now
suppresses the DeadSystemException stack traces, since they're
misleading and just added pressure to the precious log buffer space.
Add some extra RuntimeInit checks to suppress logging-about-logging
when the system server is dead.
Bug: 27364859
Change-Id: I05316b3e8e42416b30a56a76c09cd3113a018123
/frameworks/base/core/java/android/os/StrictMode.java
|
| 344744b49633a7f8aa0c8e43469bbfcf9d8e2cab |
|
29-Jan-2016 |
Jeff Sharkey <jsharkey@android.com> |
Exposing file:// beyond your app is bad, m'kay?
For several releases now we've told developers that sharing raw files
between apps is a recipe for trouble. There are at least three major
problems with sending raw files:
-- Apps sending generic intents can't know who is at the other end,
so they may not have access to shared storage locations. This is
more likely now that runtime permissions require apps to explicitly
ask users for permission.
-- Apps making files in their private storage world-readable has been
deprecated for several releases, and now in N it's fully blocked. If
we let these intents through, the receiving app would fail to open
the file, when the real blame rests on the sending app.
-- Devices with user profiles can't share raw files when using
cross-profile intent filters, since filesystem access is fully
locked down between users.
The time has finally come to communicate clearly that if you're
sharing content between apps, you need to use content:// Uris. We
added the simple FileProvider several years ago to give apps a clean
way to migrate with minimal work on their part.
Bug: 26860922, 9069185
Change-Id: I075f627f6a0d6c7fca2c090ca133b9aae9801c64
/frameworks/base/core/java/android/os/StrictMode.java
|
| f4a6dc52b1aa8a2eb216d1893741904228e1d9fe |
|
03-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
Merge "StrictMode: fix deserialization of ViolationInfo on large stacks" am: 29e0b6e789 am: af588a31bc
am: 630f658108
* commit '630f65810860cbd15012a1d5e83a275695e332cd':
StrictMode: fix deserialization of ViolationInfo on large stacks
|
| 06af46922ee5ad46f9269713f7a11ddbb6e748b6 |
|
16-Oct-2015 |
Gavin Li <git@thegavinli.com> |
StrictMode: fix deserialization of ViolationInfo on large stacks
When a large stack trace is encountered, one too many ViolationInfo
objects would be drained, which may cause a system_server crash
when readStringArray() is called on incorrect data.
Change-Id: Icb30d0402638ea5b6d63004b598d2f0bb276d685
/frameworks/base/core/java/android/os/StrictMode.java
|
| b4982b20cde31e4c507c762c448e00ac820e6264 |
|
17-Sep-2015 |
Ryo Hashimoto <hashimoto@google.com> |
Use the proper variant of String#substring to report broken strict mode stacks
substring(int start) returns everything after |start|.
To get the front part, substring(int start, int end) should be used.
Change-Id: I4dfde175f607091b48f90afe92ef3b957ffd1c6b
/frameworks/base/core/java/android/os/StrictMode.java
|
| 30e8a36de13901c0a9b4c8bebfce36f762458129 |
|
15-Jul-2015 |
Mathieu Chartier <mathieuc@google.com> |
am ad4a285a: am ebac4d1b: Merge "Change conditionallyCheckInstanceCounts to use countInstancesOfClasses"
* commit 'ad4a285af619ea29f79dbe4da19061c49f24a8c9':
Change conditionallyCheckInstanceCounts to use countInstancesOfClasses
|
| 82f91da700445c4606faea45ac8f0dc9f2857471 |
|
14-Jul-2015 |
Mathieu Chartier <mathieuc@google.com> |
am ad4a285a: am ebac4d1b: Merge "Change conditionallyCheckInstanceCounts to use countInstancesOfClasses"
* commit 'ad4a285af619ea29f79dbe4da19061c49f24a8c9':
Change conditionallyCheckInstanceCounts to use countInstancesOfClasses
|
| d288a266723e18d846ea1215919f7a377504225b |
|
10-Jul-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change conditionallyCheckInstanceCounts to use countInstancesOfClasses
countInstancesOfClasses allows passing multiple classes unlike
countInstanceOfClass. This provides a speedup since we dont traverse
the heap multiple times.
Changed ActivityThread.dumpMemInfo to do a GC since countInstancesOfClass
no longer does GC before counting.
https://code.google.com/p/android/issues/detail?id=177552
Change-Id: Ia85684f40cf59a52aa71a8479c711a994651209b
/frameworks/base/core/java/android/os/StrictMode.java
|
| fde298e738310cce29bac5e271bc6b59076f019f |
|
23-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #21254610: StrictMode uses Log.wtf which crashes apps on L+
Raise the limit at which we consider the strict mode trace to
be unreasonably large.
Change-Id: I5ec5332dd5aa2631e017d246e4a8b978b82cf318
/frameworks/base/core/java/android/os/StrictMode.java
|
| 39bf9a1916d929921597dfe3607e77561ec86569 |
|
14-May-2015 |
Alan Viverette <alanv@google.com> |
Add example for detectResourceMismatches()
Bug: 21043958
Change-Id: Iff6811539f249cbc4fbeebf63e02f62c4a2b0c95
/frameworks/base/core/java/android/os/StrictMode.java
|
| 2e5716417ee8053ba587da6469c7f20155b87172 |
|
22-Jan-2015 |
Jeff Sharkey <jsharkey@android.com> |
Public API for StrictMode cleartext detection.
Bug: 18335678
Change-Id: I4c3fd72303ae86f0c85f99ce9bdfd2913296a256
/frameworks/base/core/java/android/os/StrictMode.java
|
| d28f0fee61d28ab3369e9d9a27db9dafbb0a6eb6 |
|
16-Jan-2015 |
Narayan Kamath <narayan@google.com> |
am 2488c0ad: am 27d3e790: am 706f6cf3: Merge "Fix a property name that\'s longer than 31 chars."
* commit '2488c0ad505846f7655a7434006edea4515b02d0':
Fix a property name that's longer than 31 chars.
|
| e5515772af844b3d83e87e2747cdde4e6e076802 |
|
16-Jan-2015 |
Narayan Kamath <narayan@google.com> |
Fix a property name that's longer than 31 chars.
The name wasn't chosen without much thought and is intended
to be a temporary fix to keep devices booting while a better
name is decided upon.
bug: 18335678
Change-Id: Ic3451255d870f3395cfbcaa08a7764d93defc350
/frameworks/base/core/java/android/os/StrictMode.java
|
| 0ec9c29fb724eef676d2472f2e15904ff8f52cc0 |
|
16-Jan-2015 |
Jeff Sharkey <jsharkey@android.com> |
am c2ae6fb9: Merge commit \'605eb79c9519307147fc1795d0eb155638a7f542\' into manualmerge
* commit 'c2ae6fb9ada52e9c990542a6d1cae80085318f31':
Offer to detect non-SSL/TLS network traffic.
|
| 605eb79c9519307147fc1795d0eb155638a7f542 |
|
04-Nov-2014 |
Jeff Sharkey <jsharkey@android.com> |
Offer to detect non-SSL/TLS network traffic.
Introduces new module that provides network-related features for
the StrictMode developer API. The first feature offers to detect
sockets sending data not wrapped inside a layer of SSL/TLS
encryption.
When a developer enables, we ask netd to watch all outgoing traffic
from our UID, and penalize us accordingly if cleartext sockets are
detected. When enabled, netd captures the offending packet and
passes it back to the owning process to aid investigations. When
death penalty is requested, all future traffic on the socket is
blocked, which usually results in a useful stacktrace before the
app is actually killed.
Bug: 18335678
Change-Id: I3adbc974efd8d3766b4b1a23257563bb82d53c29
/frameworks/base/core/java/android/os/StrictMode.java
|
| 6bbb47b7d5ac1b49d916679e5f081fe181d8f162 |
|
06-Jan-2015 |
Alan Viverette <alanv@google.com> |
Clean up TypedArray docs & formatting, remove coercion warnings
Establishes a clear contract regarding when exceptions will be thrown,
when default values will be returned, and when values will be coerced
to a different type.
Since we have both getInt() and getInteger() where one handles coercion
without throwing an exception, it seems reasonable that we should clearly
document the behavior so that developers can make an informed decision.
Once we document the behavior, there is no reason to log warnings on
coercion. If a developer chooses to use a particular API or data type,
that is still correct according to the API.
BUG: 18625719
Change-Id: I385f0b719182d3c0358943e1d6c3d7bedc756eb5
/frameworks/base/core/java/android/os/StrictMode.java
|
| 9bb3dacbf9da4dae2cc0585c2e382c8b29476d32 |
|
06-Oct-2014 |
John Spurlock <jspurlock@google.com> |
Fix NPE in StrictMode handling.
Bug:17875462
Change-Id: I0bf31abe2d07335addd57976aca110565bb63cc4
/frameworks/base/core/java/android/os/StrictMode.java
|
| d867b7c7a2c8c151c01b57597b6612ca5355a51a |
|
03-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #17783882: AUPT: NPE in Videos: Attempt to invoke virtual method...
...'java.lang.String java.lang.String.substring(int)' on a null object reference
Change-Id: I4a78653174da398a4edd23b2bc099598548b79c2
/frameworks/base/core/java/android/os/StrictMode.java
|
| 8d05172112436a81bed6e4a0810f8914509d8a4d |
|
01-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #17656716: Unhandled exception in Window Manager
Fix Slog.wtf to not acquire the activity manager lock in its code
path, so that it can never deadlock. This was the original intention
of it, but part was missed.
Now we can put back in the code to detect when strict mode data is
getting large (a little more targeted now to the actual problem),
and use Slog.wtf to report it. And as a bonus, when this happens
we will now clear all of the collected violations, to avoid getting
in to the bad case where IPCs start failing. So this should be
good enough for L to fix the problem, with wtf reports for us to
see if the underlying issue is still happening.
Finally, switch a butch of stuff in the system process from Log.wtf
to Slog.wtf, since many of those are deadlocks waiting to happen.
Oh and fix a crash in the settings provider I noticed in APR.
Change-Id: I307d51b7a4db238fd1e5fe2f3f9bf1b9c6f1c041
/frameworks/base/core/java/android/os/StrictMode.java
|
| ce92b0d070c4967914698b4e257c203d7121c972 |
|
30-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #17656716: Unhandled exception in Window Manager
Drop down the limit on when we log, since under normal operation we
will never get more than a few K of data due to strict mode.
Try to clean up the code paths coming in and out of binder IPCs to
plug any places where we could disrupt the gather flag of a thread,
causing it to keep gathering stack crawls (which is the thing that
is causing our strict mode data to become so large).
Change-Id: I9a46512283d33e863c429840b465855d1fabb74e
/frameworks/base/core/java/android/os/StrictMode.java
|
| 73d6a821aeecd6003c70c32f7ae6c38f062c4290 |
|
29-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #17656716: Unhandled exception in Window Manager
Remove the checks for large parcel sizes. Those were triggering,
and identifyng the area of the problem, but also cause a lot of
trouble by making the unsafe deadlocky code there much more likely
to deadlock.
Add logging for strict mode IPCs, since those seem to be the
problem. Only log when things look bad.
Also add a log when battery stats are reset, to diagnose why they
are getting reset when they shouldn't be.
Change-Id: I588c858fb8d8c45f3c9c164ae2de9ae01547b304
/frameworks/base/core/java/android/os/StrictMode.java
|
| 6f3a38f3afd79ed6dddcef5c83cb442d6749e2ff |
|
16-Jan-2014 |
Jeff Sharkey <jsharkey@android.com> |
Run finalizers before counting for StrictMode.
Otherwise we sometimes end up counting objects strongly referenced
by the finalizer queue, and falsely detecting an instance leak.
Bug: 12533002
Change-Id: I144c941a3dfb0cbb837b98e80d2f49ffc9ca13c7
/frameworks/base/core/java/android/os/StrictMode.java
|
| 8c84109b9fbbf473b225707a38261ff5f99d95fb |
|
24-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Use FastPrintWriter... everywhere.
One problem this turned up is, because FastPrintWriter does
its own buffering, a lot of code that used to use PrintWriter
would fail -- if it pointed to a StringWriter, there was no
buffering, so it could just immediately get the result. Now
you need to first flush the FastPrintWriter.
Also added some new constructors to specify the size of buffer
that FastPrintWriter should use.
Change-Id: If48cd28d7be0b6b3278bbb69a8357e6ce88cf54a
/frameworks/base/core/java/android/os/StrictMode.java
|
| a2934d5ff0b5c4098408cd583c2c259edf37c118 |
|
14-Jun-2013 |
Jeff Sharkey <jsharkey@android.com> |
Cache AndroidBlockGuardPolicy to avoid allocation.
Every incoming Binder call ends up triggering a BlockGuardPolicy
update, which would thrash between new AndroidBlockGuardPolicy
instances and BlockGuard.LAX_POLICY, causing GC churn.
This change avoids the extra allocations by recycling a single
AndroidBlockGuardPolicy in a ThreadLocal. Worst-case thrashing case
is now 10% faster; from 7.46us to 6.65us.
Bug: 9424568
Change-Id: I9c3b1c097a2aecc9b1f109a824cf3ea319fb3393
/frameworks/base/core/java/android/os/StrictMode.java
|
| 390517be2d60dd6e6264150c190c372d89bb331a |
|
31-May-2013 |
Dianne Hackborn <hackbod@google.com> |
Clean up some temporary allocations.
Yay to ArrayMap, letting me get rid of a bunch of temporary
iterators in core code paths like updateOomAdj. (Now I definitely
need an ArraySet to finish that up.)
Also clean up various other things that are doing unnecessary
allocations, clean up some debug output, make more of the debug
output respect package filtering.
Change-Id: Ib4979faf4de8c7912739bc0937c3fa9e7bfcde67
/frameworks/base/core/java/android/os/StrictMode.java
|
| 0fa30372c7768692f9deef3e33655382e8a683fd |
|
04-Apr-2013 |
Ying Wang <wangying@google.com> |
Fix doc build.
Change-Id: I954a45866d968b0571040ba99cc93b818d02aeb5
/frameworks/base/core/java/android/os/StrictMode.java
|
| a14acd20b8d563319ea1a5974dca0e9a29f0aaef |
|
03-Apr-2013 |
Jeff Sharkey <jsharkey@android.com> |
Warn when exposing file:// Uris beyond a process.
Check for file:// Uris inside Intents, ClipData, Notifications and
RemoteViews when StrictMode option is enabled.
Also introduces Intent.prepareToLeaveProcess() to uniformly handle
Intents about to leave an app process.
Bug: 8529070
Change-Id: I8efb43877cbc5f21eb029fc6492b3ee1415059ef
/frameworks/base/core/java/android/os/StrictMode.java
|
| 097fbf2e98e0d32baf6cbd1a5659c4145afb191f |
|
13-Jul-2012 |
Qi Wang <wangqi0316@gmail.com> |
StrictMode.permitCustomSlowCalls() should call disable(DETECT_CUSTOM)
/frameworks/base/core/java/android/os/StrictMode.java
|
| 3761f33387f980d7a6c6e06555a5a932ba7247a2 |
|
16-Mar-2012 |
Jeff Sharkey <jsharkey@android.com> |
Move StrictMode timers to postAtFrontOfQueue().
StrictMode posts a message to estimate how long the main thread was
blocked during a violation. Currently, any pending messages are
counted against the violation. To avoid this, switch to using
postAtFrontOfQueue().
Bug: 6119289
Change-Id: I94530632ca678b78b75a698cf9193641b102be9a
/frameworks/base/core/java/android/os/StrictMode.java
|
| e61cad321d2888f2b6b7e0322158211e3b3e0c46 |
|
08-Mar-2012 |
Dirk Dougherty <ddougherty@google.com> |
resolved conflicts for merge of 532679a5 to master
Change-Id: Id60d047c0e1f288acff97526c016cca632873b6b
|
| 4d7bc65538c7cd9fbb1fbbcf22d1da47fcee1219 |
|
28-Jan-2012 |
Dirk Dougherty <ddougherty@google.com> |
Doc change: String changes for Android Market
Change-Id: I823812a4fd24021bec906ad856479c92a8d2a759
/frameworks/base/core/java/android/os/StrictMode.java
|
| d7026f1612a7c1e8cc9b484038fa99b7fc29cfd7 |
|
02-Mar-2012 |
Jeff Sharkey <jsharkey@android.com> |
Report leaked Context registrations to StrictMode.
When tearing down any leaked BroadcastReceiver or ServiceConnection
Context registrations, report through StrictMode.
Bug: 6084353
Change-Id: I5e78039299e2c9c1440cd1fd09317da78ffee82a
/frameworks/base/core/java/android/os/StrictMode.java
|
| bc6f0ce8be64a74b695fb21dab5f4805b68dce16 |
|
03-Nov-2011 |
Christopher Tate <ctate@google.com> |
Add persistent property to disable strict mode
Setting persist.sys.strictmode.disable to 'true' will disable strict
mode on eng/userdebug builds where it is turned on by default.
Explicitly enabling it in the Settings UI will override this, so
it's still possible to toggle it there even when this property
has been set on the device.
Change-Id: Ifd971f948fb2f803d509c2a06112c4bb932a5b1f
/frameworks/base/core/java/android/os/StrictMode.java
|
| be7c29c9f7e3d7b75d4374c8b5c0ca43c9d09c68 |
|
11-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Don't log BlockGuard violations on ENG builds.
We want to see CloseGuard violations in the log in ENG builds
because they indicate serious problems, but BlockGuard is
too noisy and is best viewed in the aggregate from the
drop box based tools.
Change-Id: I77d4d0a561a4299355c111d0ccb5a2147646245b
/frameworks/base/core/java/android/os/StrictMode.java
|
| d5875d98f06817f78bd974842a8a9c2d41802d20 |
|
09-Oct-2011 |
Jeff Brown <jeffbrown@google.com> |
Always log StrictMode violations on ENG builds.
The drop-box is too quiet and it masking real problems from
developers. On ENG builds, use both logging and the drop-box
to ensure that problems are noticed promptly.
Change-Id: Id8fb8d392a7e01b532b73cb1a026b0d1f17af742
/frameworks/base/core/java/android/os/StrictMode.java
|
| 7e442837702a6e026c73a01fedb62c222b63cfc9 |
|
11-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Optimize StrictMode activity instance count check.
This change attempts to avoid a periodic and costly 110ms
explicit GC and instance count operation when StrictMode
activity leak checking is enabled.
Change-Id: Ia90289ac3352c01c797ab3cc25456e3db68f220a
/frameworks/base/core/java/android/os/StrictMode.java
|
| 08d584cd1cba05284ccd2d0ea128c297624f0c47 |
|
17-May-2011 |
Steve Block <steveblock@google.com> |
Log a StrictMode violation when WebView methods are called on the wrong thread
Bug: 4373919
Change-Id: I1f526e033ce316e51b3de7fe4ac88119fbc65b4e
/frameworks/base/core/java/android/os/StrictMode.java
|
| c0bb0bb5e3425b77b6e7820ebe25fe72bdd07782 |
|
21-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: set sIsIdlerRegistered to false, and don't register if no penalties
Change-Id: I1b2531b66d09c850519af17918aed8be9853ef3b
/frameworks/base/core/java/android/os/StrictMode.java
|
| 5f8b5c191cae77f536ee64f0b625e4a7f8596787 |
|
21-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
Fixes for StrictMode instance count checking.
Misc stuff found after looking at the first day of data, Jesse's
review, and comments from Dianne about tracking Activity counts
better.
Change-Id: Ifee1ef8f59f41061d4aac8c02765627dbf3cd8e4
/frameworks/base/core/java/android/os/StrictMode.java
|
| bfbe5771106a07f9c8e8685e402b1003db40526f |
|
19-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: class instance limits (track object "leaks")
Change-Id: I2db5a19060c2013078feb88a91caf655469b2f98
/frameworks/base/core/java/android/os/StrictMode.java
|
| 758035757f11a085a12b54daa9467f1d6bb251ef |
|
13-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode class instance limit interface.
Change-Id: Ic5eea539586e5d4965d83364bf9f623d1d89f2b1
/frameworks/base/core/java/android/os/StrictMode.java
|
| 4a82b620443269e0954ebb0743d8b42f0e76bc3e |
|
14-Jan-2011 |
Brad Fitzpatrick <bradfitz@android.com> |
Remove accidental StrictMode logging left in.
Change-Id: I7580816c6efc32889f49987152ff1d4c40d47140
/frameworks/base/core/java/android/os/StrictMode.java
|
| 4e920f70f38d52d3a74c6a3133388a2e2cb6c175 |
|
14-Dec-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Add MODE_MULTI_PROCESS flag to Context.getSharedPreferences()
Also, changes to make this testable with CTS:
-- special PENALTY_DEATH StrictMode fast path that doesn't use
the Looper idling to "time" the violation. Only used when
death is the only violation,
-- make PENALTY_DEATH throw a RuntimeException instead of
killing its process with a signal. this means we can catch
it in CTS tests, but it's also more consistent with
PENALTY_NETWORK_DEATH in Honeycomb.
-- make FileUtils.getFileStatus() invoke StrictMode, which isn't
(yet?) aware of I/O in native code. so help it out.
CTS test for MODE_MULTI_PROCESS is in I6154edab
Change-Id: Icf93f9dfb0ece06b16781e4803dd2c17df3cf1b3
/frameworks/base/core/java/android/os/StrictMode.java
|
| 996f41da3ca69844ffeee9f8e9ae7423bf440788 |
|
14-Dec-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
am 2d5b11ab: am 0927c902: Merge "Fix StrictMode javadoc copy/paste error." into gingerbread
* commit '2d5b11aba0fec21e1ce3f358eb0d280b62704899':
Fix StrictMode javadoc copy/paste error.
|
| 320274c5f17057a3a823fed50b7027cbd46fc025 |
|
13-Dec-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Fix StrictMode javadoc copy/paste error.
Change-Id: Idd49111f0a1af6f331cffa0972191b2d4e25a385
/frameworks/base/core/java/android/os/StrictMode.java
|
| e36f9bf123c7cd07ce1007a16de564b2840ea1fe |
|
10-Dec-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode "custom" trigger support.
For people who want to annotate their own functions as slow, outside
of just the built-in disk & network stuff.
Change-Id: Ia90e150d1cf7a23a658c091285c1c8bb2d7d9732
/frameworks/base/core/java/android/os/StrictMode.java
|
| bea168c09d173fb99cfc91c562c4a497a5e7d2d2 |
|
30-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: more accurate timings
Don't wait for animations to finish before clicking stopwatch. (see
comments in the patch for details)
Change-Id: I73f87b2b787d6db19deb0171a2457ff5fc875d3d
/frameworks/base/core/java/android/os/StrictMode.java
|
| f54545927f365d6e55cbf66ff9f7ffe91aada774 |
|
25-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Don't flash StrictMode from the system server.
These are false positives from a developer's point of view.
Change-Id: Ic8baf81c0e2cf559a38c1fe6adfa6e739dd3eaed
/frameworks/base/core/java/android/os/StrictMode.java
|
| c1a968a8ed45181312f7d4bcdbba0cc8ddc201ba |
|
24-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Option to enable StrictMode flashing on userdebug builds.
Change-Id: Ifc8e733ea0e0f6bda234a18ad84bcd230879e802
/frameworks/base/core/java/android/os/StrictMode.java
|
| 1065685400335ef8c1220f34b4e896e7da603789 |
|
24-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Fix potential weird StrictMode NPE.
Seen once in an eng build. Could in theory happen if there was a
violation in the system server before the activity manager was
registered.
Change-Id: I785f06848af0e2af4657be3a8edbbd658eeb3cf2
/frameworks/base/core/java/android/os/StrictMode.java
|
| f3d86be6d7d2999cd6bae236817688490df7da71 |
|
23-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode fingerprinting / hashCode improvements.
Change-Id: I08ff939327f7c11a562851847ae91c67b1db4f87
/frameworks/base/core/java/android/os/StrictMode.java
|
| cdcb73ef781b8f7d37d9f758409a0c7671517b37 |
|
23-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Cache WindowManager in StrictMode; add android.util.Singleton
Change-Id: I15a85461424de930710d4901658440b5d305cabb
/frameworks/base/core/java/android/os/StrictMode.java
|
| 6804433b0af50f33a338307ae8ddb50bc49e886b |
|
23-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode visual notification support.
Change-Id: I64a5adb683060d9649f1132414547bb3c346a2a8
/frameworks/base/core/java/android/os/StrictMode.java
|
| bee248769d51adb335b71b329b3d7813c5c71851 |
|
20-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: dropbox VM-wide violations (e.g. CloseGuard) async
To be clear, the dropbox violations were already async in the
ActivityManager, but the Binder call was often 30 ms anyway.
This optimization was already done for per-thread violations earlier,
but was never done for VM-wide violations because they weren't common,
until CloseGuard came about. Now that CloseGuard fires a lot, apply
the same optimization to VM-wide violations.
This CL also addresses a concern of Dianne's earlier of too many
threads being outstanding. So now there's a paranoia check with an
upper bound on how many outstanding ActivityManager calls are
in-flight.
Change-Id: I95e0816105ab862f0f241052b149c9a46a70ce9c
/frameworks/base/core/java/android/os/StrictMode.java
|
| 82829ef3b7c72bee36d8c17b36ac565f1856a310 |
|
19-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: use Log.isLoggable
Change-Id: Ic28450066a43a168cfe3026d6d4b06b752f8423c
/frameworks/base/core/java/android/os/StrictMode.java
|
| d188ededa6f61dbe5a700e81db22c02478ce60cc |
|
18-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: shut up VM penalty logging on debug builds.
Thread penalties were just dropboxing, but VM penalties were both
dropboxing *and* logging, and most annoyingly.
Change-Id: Ifc64b642dd0e2b17f0234ce3724650489883f62b
/frameworks/base/core/java/android/os/StrictMode.java
|
| 1cc13b6d1cc7203ad126b0708f0bf697e111264f |
|
17-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Annotate ListView with StrictMode.Span
Change-Id: Ibee1bfa73c85dac2e8103eb5900f0609cbb30ee7
/frameworks/base/core/java/android/os/StrictMode.java
|
| 1181cbbfd7c913c51d9836272ad30cfe851c4699 |
|
16-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Fast no-op path for StrictMode.Span on user builds.
Change-Id: I3eb75288d670a8ac1e10547715d8c1a855a5fdc9
/frameworks/base/core/java/android/os/StrictMode.java
|
| 7c2ae6570321575ad74a25bdc72bea1ec6558660 |
|
14-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Fix CloseGuard/StrictMode integration.
Change-Id: Ib89843c48b92138d3981f0f719eae28bf44e2ed4
/frameworks/base/core/java/android/os/StrictMode.java
|
| e7520d89fe2c5dc9dd833ecd9769c981df855b61 |
|
11-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode.Span support
Support for annotating critical regions (e.g. animations) with
a tag to be uploaded.
Change-Id: I412fc78f40dc05c9a3c9f62a4b0463201dbdb767
/frameworks/base/core/java/android/os/StrictMode.java
|
| 4b9b7c38e8f52259f9d2f960072d35e8a1ab2129 |
|
08-Nov-2010 |
Brian Carlstrom <bdc@google.com> |
Add custom CloseGuard.Reporter for StrictMode
StrictMode now replaces the default CloseGuard.Reporter with one that
calls onVmPolicyViolation, which is a renamed version of
onSqliteObjectLeaked.
Change-Id: Iea980662e2ee91939960c83b8768a8172379617a
/frameworks/base/core/java/android/os/StrictMode.java
|
| fd9ddd1a40efc801dc7512950cb9336967b6f775 |
|
04-Nov-2010 |
Brian Carlstrom <bdc@google.com> |
Integrate StrictMode with CloseGuard
In additional to adding the StringMode API for controling CloseGuard,
this checkin fixes several CloseGuard issues found booting a device.
Bug: 3041575
Change-Id: I4dffd184f49438d6d477ed81a1c2a2a5b56cc76b
/frameworks/base/core/java/android/os/StrictMode.java
|
| bfb191998eba2ebc710ff9eb59480b10909ba4c9 |
|
30-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: annotate violations with the Broadcast Intent's action, if any.
Change-Id: If36ab776bb95054a109b5475c6be041c75c7e0af
/frameworks/base/core/java/android/os/StrictMode.java
|
| b6e18412af35bf724298796eed65ef1fbbe1925e |
|
28-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Make network usage on the main thread fatal (Honeycomb+)
For apps targetting Honeycomb SDK or above, make network usage on the
main thread (aka event thread, Looper thread, UI thread) be fatal.
If an app is targetting a previous SDK version, they're grandfathered
into the older (lack of) rules.
Bug: 786847
Change-Id: Ia4ae77b8369567ee526c96b930d523bc722b0bc9
/frameworks/base/core/java/android/os/StrictMode.java
|
| 71678ddcc45d9cd4557f3bed8bba5382bf36b68b |
|
28-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: optimize common case (just dropboxing)
The way StrictMode is used during development, just dropboxing
violations, could be a little more optimal, taking the
ActivityManagerService call off the main thread. But we can only do
this safely in the case where that's the only penalty.
Data suggests this call, despite being async, still takes around 30
milliseconds. This isn't a major win, and arguably it might be a
_better_ idea to slow down people's event loops more and further jank
up their animations on violations, but I thought any less overhead
from StrictMode, the better.
Change-Id: Iad9cce1cb4a084fa64abc4b5e1b4f3bff6a08c94
/frameworks/base/core/java/android/os/StrictMode.java
|
| 599ca29986235e07f532c7b112507f6c39b5dba9 |
|
22-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Expose (internally only) the number of animations currently running.
This will be used for StrictMode to annotate violations with
whether or not they janked up an animation.
Change-Id: I5bc691f49b74c45279cd2ae044d2a81dcf1204a9
/frameworks/base/core/java/android/os/StrictMode.java
|
| 62a1eb58bfafe8744d7a65f651e11b88fdb0938d |
|
18-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: fix docs to actually compile and add a utility method.
Yes, this is a last minute public API change, but I'm already getting
a lot of inquiries about how to use StrictMode on a GB device but
targetting Eclair or Froyo. I'd like a simple answer involving
reflection, but the current API is too painful to use via reflection.
I imagine this will be a common request, and it's much easier for us
to write a little blog post about trying it out if there's an easy way
to use it with reflection.
Change-Id: I1f21aaac7e61e5e90d1e4facc0c787d8daf089b1
/frameworks/base/core/java/android/os/StrictMode.java
|
| 9fc2fc5757a3d28d098bd2b0ad0f869a3cf3fa14 |
|
11-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: link to designing for responsiveness ANR docs
Change-Id: If65849aaa8317e7e40b2837b640a5cdb95fe7b0e
/frameworks/base/core/java/android/os/StrictMode.java
|
| 191cdf023c3c1ab441087a77f7881c7bb376613a |
|
11-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: check max-offenses-per-loop earlier, before allocations
Previously a tight loop of StrictMode violations would still allocate
Exception objects and populate their stack frames, just to orphan them
later when checking the max-10-violations-per-loop constraint.
With this patch, we do that check _before_ allocating any memory.
Change-Id: Iae96aba33f8fcc6a8ec5838a231aecc08e95122d
/frameworks/base/core/java/android/os/StrictMode.java
|
| 32e60c7942eeba920ec5c27b372ec0899fd75a20 |
|
01-Oct-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Update StrictMode's public API.
This makes it more future-proof and maintainable, not exposing the
internal bitpacking state.
The implementation is unchanged (the policy is still just an int we pass
around).
Also starts to introduce VmPolicy, for things which are process-wide,
not per-thread. As an initial user, make SQLite's Cursor finalization
leak warnings use StrictMode.
Change-Id: Idedfba4e965716f5089a52036421460b1f383725
/frameworks/base/core/java/android/os/StrictMode.java
|
| 15ba4061116e088d62a7e05a0037f294f31dff06 |
|
22-Sep-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Flesh out StrictMode docs.
Bug: 3001474
Change-Id: If64209a312d45f7d96d8317d1e63e6c773a01441
/frameworks/base/core/java/android/os/StrictMode.java
|
| 50d66f9fcdac84b2af65a82be56728f54b1a7ef0 |
|
14-Sep-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Unify some duplicate StrictMode-enabling code.
Change-Id: Ifb92f35d9e245dbdb5e201597d8be702bce9e8b8
/frameworks/base/core/java/android/os/StrictMode.java
|
| 97461bd25c3821f3fb6af9705f0612259c6b4492 |
|
24-Aug-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Some StrictMode API changes.
* rename setThreadBlockingPolicy to setThreadPolicy (opens the way to
using StrictMode for non-blocking-related things in the future?)
* add allowThreadDiskWrites() and allowThreadDiskReads() to modify the
current policy mask and return the old one. this will allow turning
off part of StrictMode during certain regions of code. (for
instance, writing to disk in Activity onPause...)
Change-Id: Ia1878153713f79299971fdab567fa15b3cb9d56c
/frameworks/base/core/java/android/os/StrictMode.java
|
| cb9ceb1029036363a81952d8ed5dfcbc83e6ff72 |
|
29-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: time violations in Binder calls
Change-Id: I5796993dce98be722cf679b78acaf0c9de0ba461
/frameworks/base/core/java/android/os/StrictMode.java
|
| 7bcad8a315f12bd6251a998781efac7b11c2ca84 |
|
27-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Replace several IPCThreadState::get() lookups with one.
Also, make StrictMode's ThreadLocal final.
Change-Id: I08d400ed254fa67bb7a3dae1227f205a54c00df0
/frameworks/base/core/java/android/os/StrictMode.java
|
| 703e5d3c7fbeb8ca0978045db01d40318f838612 |
|
15-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: avoid an allocation in common case
Make the initialValue() of the ThreadLocal be null, so checking it doesn't
cause one to be created in the case of an RPC call not using StrictMode.
Change-Id: I3ea19ce444a1b3c39a6e53c5cb5d4faf4b07a6c8
/frameworks/base/core/java/android/os/StrictMode.java
|
| 5b747191ff8ad43a54d41faf50436271d1d7fcc8 |
|
12-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: gather and return violating stacks in Binder replies
Now, when Thread A has a strict mode policy in effect and does a
Binder call to Thread B (most likely in another process), the strict
mode policy is passed along, but with the GATHER penalty bit set which
overrides other policies and instead gathers all offending stack
traces to a threadlocal which are then written back in the Parcel's
reply header.
Change-Id: I7d4497032a0609b37b1a2a15855f5c929ba0584d
/frameworks/base/core/java/android/os/StrictMode.java
|
| 727de40c6bc7c6521a0542ea9def5d5c7b1c5e06 |
|
08-Jul-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
More StrictMode work, keeping Binder & BlockGuard's thread-locals in-sync.
Change-Id: Ia67cabcc17a73a0f15907ffea683d06bc41b90e5
/frameworks/base/core/java/android/os/StrictMode.java
|
| 143666f0ca28f0e3e6597e5025078f0449ca6abe |
|
14-Jun-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
StrictMode: implement the log-to-DropBox option
Change-Id: I51d12e264155078f953028241f8c5cbdc47262e8
/frameworks/base/core/java/android/os/StrictMode.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/core/java/android/os/StrictMode.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/core/java/android/os/StrictMode.java
|