summaryrefslogtreecommitdiff
path: root/core/java/android/os/StrictMode.java
Commit message (Collapse)AuthorAgeFilesLines
* Migrate frameworks/base javadocs references to androidxAlan Viverette2022-02-091-1/+1
| | | | | | | | | | | Does not remove Support Library artifacts from docs classpath (ApiDocs.bp) because they are still used in development/samples, which is not as easy to migrate as javadoc. Bug: 158779503 Test: make docs Exempt-From-Owner-Approval: Mass find/replace for androidx migration Change-Id: Icf7f53ec36a0e970413352e2ebf40ce9d60ed17e
* Revert "Revert "Migrate unsafe parcel APIs in framework-minus-apex""Bernardo Rufino2022-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 331be9a6431d6489f8d1e1b80cb510d0ee073c50. Reintroducing ag/16366278 since it seems unrelated to b/214053959 (more details on b/214053959#comment55). Original commit message: Migrate unsafe parcel APIs in framework-minus-apex Migrate the following unsafe parcel APIs in framework-minus-apex: * Parcel.readSerializable() * Parcel.readArrayList() * Parcel.readList() * Parcel.readParcelable() * Parcel.readParcelableList() * Parcel.readSparseArray() This CL was generated by applying lint fixes that infer the expected type from the caller code and provide that as the type parameter (ag/16365240). A few observations: * In some classes we couldn't migrate because the class also belonged to another build module whose min SDK wasn't current (as is the case for framework-minus-apex), hence I suppressed the lint check (since I'll eventually submit the lint check to the tree). * In some cases, I needed to do the cast in https://stackoverflow.com/a/1080525/5765705 to make the compiler happy since there isn't another way of providing a class of type Class<MyClassWithGenerics<T>>. * In the readSerializable() case, the new API also requires the class loader, that was inferred to by InferredClass.class.getClassLoader(). * Note that automatic formatting and import rely on running hooked up to the IDE, which wasn't the case here. Bug: 195622897 Change-Id: I272432e6e082a973f7a50492ec35d79c2b577c93 Test: TH passes
* Merge "Revert "Migrate unsafe parcel APIs in framework-minus-apex""Ashwini Oruganti2022-01-121-1/+1
|\
| * Revert "Migrate unsafe parcel APIs in framework-minus-apex"Bernardo Rufino2022-01-121-1/+1
| | | | | | | | | | | | | | | | This reverts commit 90bb3709dc75f7e44914222114752de5bce133d4. Reason for revert: b/214053959 Change-Id: Ic271bab1d3eaf677a5989dda9deb944ee2ad6850
* | Merge changes from topics "ms34-tm", "ms40-clock" am: beb9fb3cc8 am: ↵Junyu Lai2022-01-061-0/+9
|\ \ | |/ |/| | | | | | | | | | | 08c51b04ca am: d312550ff8 am: f23caacaf1 Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1914533 Change-Id: I7db7bdf217c982ef6011a948b68d238c54e2a47e
| * [MS27] Expose noteUntaggedSocket SystemApiJunyu Lai2022-01-061-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While Data usage related codes are moving to mainline module, StrictMode#vmUntaggedSocketEnabled() and onUntaggedSocket() can no longer be accessed from NetworkManagementSocketTagger. Thus, expose alternative SystemApi to allow invocations from the module. Test: TH Bug: 204830222 Exempt-From-Owner-Approval: 1. Owner approved the change with explicitly granted submission after adderessing the straight-forward comment. 2. Owner is OOO for 3 months. Change-Id: Ib54ff54ce3617ae0d04080a1740e78b086bbb039
* | Migrate unsafe parcel APIs in framework-minus-apexBernardo Rufino2021-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Migrate the following unsafe parcel APIs in framework-minus-apex: * Parcel.readSerializable() * Parcel.readArrayList() * Parcel.readList() * Parcel.readParcelable() * Parcel.readParcelableList() * Parcel.readSparseArray() This CL was generated by applying lint fixes that infer the expected type from the caller code and provide that as the type parameter (ag/16365240). A few observations: * In some classes we couldn't migrate because the class also belonged to another build module whose min SDK wasn't current (as is the case for framework-minus-apex), hence I suppressed the lint check (since I'll eventually submit the lint check to the tree). * In some cases, I needed to do the cast in https://stackoverflow.com/a/1080525/5765705 to make the compiler happy since there isn't another way of providing a class of type Class<MyClassWithGenerics<T>>. * In the readSerializable() case, the new API also requires the class loader, that was inferred to by InferredClass.class.getClassLoader(). * Note that automatic formatting and import rely on running hooked up to the IDE, which wasn't the case here. Bug: 195622897 Test: TH passes Change-Id: I11a27b9bdab7959ee86e90aa1e1cbebd7aaf883c
* | Merge "Allow config context to inflate views" into sc-dev am: c22aff4e4dCharles Chen2021-04-091-0/+39
|\| | | | | | | | | | | Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/13482649 Change-Id: Idc103720792c36b1a1e3331a5d2bea72e87e8efa
| * Allow config context to inflate viewsCharles Chen2021-04-071-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | Besides UI contexts, the context created via Context#createConfigurationContext with a proper configuration should be allowed to inflate views or obtain ViewConfiguration. An example is that a wear device inflate views into bitmap and pass the bitmap to the Wear OS Companion app on the phone. Bug: 177847640 Test: atest StrictModeTest Change-Id: Iab232a80a973f54bf0484262d45af3e4c2f0e5dc
* | Merge "Relaxed WallpaperManager API assertion" into sc-dev am: ddb41ad5d5Charles Chen2021-03-101-3/+2
|\| | | | | | | | | | | | | | | Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/13461645 MUST ONLY BE SUBMITTED BY AUTOMERGER Change-Id: I87c9ced91b9699ee18ea7d940398637c73ffe8fd
| * Relaxed WallpaperManager API assertionCharles Chen2021-02-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | This CL relaxes the assertion to only verify the APIs query Context#getDisplayId. We don't check if the context is display context because we may change these APIs to provide the window metrics of a specific DA. Bug: 178717030 Test: atest StrictModeTest Change-Id: I34413463eb1eb675871df41f262bce9ae3fb4edb
* | docs: Can leave StrictMode enabled in prodKevin Hufnagle2021-02-061-17/+13
|/ | | | | | | | | | | Google Play now checks StrictMode elements based on target SDK version, so it's safe for apps to leave StrictMode checks enabled in their production code. Bug: 179525953 Change-Id: I5a68d4892d521f5e62c25f57621f934c39436008 Test: m ds-docs-java Exempt-From-Owner-Approval: Docs-only change
* Add StrictMode check for unsafe intent launchingJeff Sharkey2021-01-201-0/+71
| | | | | | | | | | | | | | Exported components that are not guarded by a signature permission can receive Intents from any other app on a device. If an app unparcels and launches an Intent from the Intent delivered to this unprotected component then a malicious actor can potentially craft an Intent that could launch hidden components, grant URI permissions, etc. This commit adds a StrictMode check to report if a component launches an Intent unparceled from the delivered Intent. Bug: 160796858 Test: atest StrictModeTest Change-Id: I763b8a965f91f5b433ce2f4b619e10ef12f5c296
* Limit UI context verification to UI related APIsCharles Chen2021-01-181-0/+27
| | | | | | | | | | This CL relaxed the UI context checks to only apply on UI related APIs in WallpaperManager. Test: build & run Bug: 176958992 Change-Id: I390e865e31fde48bad6bbddb4203e4c997a1400a
* Release detectIncorrectContextUseCharles Chen2020-11-191-6/+4
| | | | | | | | also link it in Context#isUiContext(Context). Test: build & run Bug: 170275820 Change-Id: Ide1195af1d11bb33a846420b92de70325c0ecf61
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-291-2/+2
| | | | | | | | | | | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. This is a resubmit of ag/12929664 with some APIs excluded that caused test failures; see bugs 171886397, 171888296, 171864568. APIs excluded: Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord; Landroid/os/Process;->myPpid()I Landroid/os/SharedMemory;->getFd()I Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I Bug: 170729553 Test: Treehugger Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
* Revert "Add maxTargetSdk restriction to unused APIs."Hongwei Wang2020-10-281-2/+2
| | | | | | | | | This reverts commit 72f07d6a8a32db4a0dedd7682a0b3385be2b9cd6. Reason for revert: Droidcop-triggered revert due to breakage https://android-build.googleplex.com/builds/quarterdeck?testMethod=testAppZygotePreload&testClass=android.app.cts.ServiceTest&atpConfigName=suite%2Ftest-mapping-presubmit-retry_cloud-tf&testModule=CtsAppTestCases&fkbb=6936597&lkbb=6936969&lkgb=6936551&testResults=true&branch=git_master&target=cf_x86_phone-userdebug>, bug b/171886397 Bug: 171886397 Change-Id: Ibe0f0430a3451477c1ee8ef56a596e91ea1e7672
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-271-2/+2
| | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. Bug: 170729553 Test: Treehugger Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
* Apply fixes for EfficientStrings.Jeff Sharkey2020-10-201-4/+5
| | | | | | | | | | Refactoring to avoid paying the cost of extra StringBuilder that are quickly disposed. Bug: 170978902 Test: none Exempt-From-Owner-Approval: trivial refactoring Change-Id: Icd914a63cdadf8123c1e5a5073f85245f0791f0b
* Apply fixes for EfficientCollections.Jeff Sharkey2020-10-201-16/+20
| | | | | | | | | | Drop-in replacements suggested for inefficient collections. Also annotate a handful of places where we're unable to update. Bug: 155703208 Test: none Exempt-From-Owner-Approval: trivial refactoring Change-Id: I48b600508df8160ac9b40fea7afca974b2c972f6
* Update language to comply with Android's inclusive language guidanceJeff Sharkey2020-09-141-1/+1
| | | | | | | | | See https://source.android.com/setup/contribute/respectful-code for reference Test: none Bug: 168334533 Exempt-From-Owner-Approval: docs updates Change-Id: Ifce5239991e3b78dd4757712e3b88093ad7161f0
* Pass in callsite of SurfaceControl constructor explicitly (1/3)Jorim Jaggi2020-06-261-0/+7
| | | | | | | | | | | | Creating a new Throwable (and filling in the stack trace) can take up to 150us. Since we do this on the critical path when sending over SurfaceControl via binder multiple times, this is too much. Instead, add an option to pass in callsite manually. Bug: 159056748 Change-Id: I46c339c15a07192d61c4c546e46f260684a47120 Merged-In: I46c339c15a07192d61c4c546e46f260684a47120 Exempt-From-Owner-Approval: Large scale refactor
* Fix memory leak in StrictMode violation throttlingJing Ji2020-06-221-16/+47
| | | | | | | | | | | | * Add hashCode() to the base Violation class for dup detections * Discard obsoleted violation fingerprints if possible Bug: 159128771 Bug: 159626227 Test: run cts -m CtsOsTestCases -t android.os.cts.StrictModeTest Test: Manual - Loop generation of StrictMode violations Test: Manual - Check heap dump Change-Id: I19a0922fe010fad97b6b819e73acb7db08f84930
* Get the instance count as the initial valueChilun2020-05-211-1/+6
| | | | | | | | | | | | | | Developer may not be able to enable strict mode before creating any activities. The initial value of expected instance count may not always be 1. This CL use the instance count from InstanceTracker as the initial value. Bug: 152348723 Test: atest ActivityLeakTests atest NexusLauncherTests Change-Id: I8d34c87748deac72cf8b6e5cc247029901bbffb3
* Fix broken @see tags in public documentation.Andrew Sapperstein2020-05-011-1/+0
| | | | | | | | | | | | | | | | | | | These were previously being suppressed by doclava but with this change, all failures are fixed and the suppression logic has been removed. To fix the issues, there were a few possible changes made: - broken reference to a public API (such as incorrect parameters): fixed - unnecessary @link inside an @see tag: fixed - @see referring to an @hide or @SystemApi: reference removed - broken references to inner class constructors - worked around by fully qualifying the constructor Bug: 6963924 Test: make doc-comment-check-docs Exempt-From-Owner-Approval: cherry-picked from master Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85 Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85 (cherry picked from commit e0624c7a40baae30cf77e948db5258b78856d0e5)
* Exempt-From-Owner-Approval: Report non-visual Context misuseAndrii Kulian2020-02-201-0/+43
| | | | | | | | | | | | | | | Make obtaining a visual service from non-visual Context instance report a strict mode violation and print the stacktrace. Make calling getDisplay() throw an exception if called on an instance that is not associated with a display. For existing usages introduce a new internal method that does not perform the verification until the usages are properly fixed. Bug: 128338354 Test: StrictModeTest#testIncorrectContextUse_GetSystemService Test: StrictModeTest#testIncorrectContextUse_GetDisplay Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
* Use new UnsupportedAppUsage annotation.Artur Satayev2019-12-181-1/+1
| | | | | | | | Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library. Bug: 145132366 Test: m && diff unsupportedappusage_index.csv Change-Id: I534e3fd1305e2f4af076986770033478448a665c
* Add @UnsupportedAppUsage to test apis that are known to be used by apps.Artur Satayev2019-11-131-0/+2
| | | | | | | | | go/testapi-enforcement Bug: 133832325 Test: m Change-Id: Ifc8db120640a1554dcbf1722e61e09c7ddc65dd6 Merged-In: Ifc8db120640a1554dcbf1722e61e09c7ddc65dd6
* Avoid triggering StrictMode for storage notifs.Jeff Sharkey2019-04-281-2/+4
| | | | | | | Bug: 130129028 Test: none Exempt-From-Owner-Approval: trivial bugfix Change-Id: Ia9d9da589ee1f4d95a27bf327235f950f65c69a0
* Add @UnsupportedAppUsage annotationsAndrei Onea2019-03-151-0/+15
| | | | | | | | | | | | | | | | For packages: android.os This is an automatically generated CL. See go/UnsupportedAppUsage for more details. Exempted-From-Owner-Approval: Mechanical changes to the codebase which have been approved by Android API council and announced on android-eng@ Bug: 110868826 Test: m Change-Id: I4ece0a3f37f88fc2508cb965092aed7cabc61819
* All Parcelable CREATOR fields are @NonNull.Jeff Sharkey2019-02-281-1/+1
| | | | | | | | | If they were null, then the Parcelable would fail to work. Bug: 126726802 Test: manual Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014 Exempt-From-Owner-Approval: Trivial API annotations
* To be @Nullable or @NonNull, that is the question.Jeff Sharkey2019-03-011-49/+49
| | | | | | | Bug: 126699288, 126699496, 126700389 Bug: 126700085, 126701638, 126702005, 126700497 Test: manual Change-Id: Idcbc2722ddcf014a9e5cef14321b4e2ce30adf9c
* Merge "StrictMode to catch storage while locked."TreeHugger Robot2018-06-301-0/+110
|\
| * StrictMode to catch storage while locked.Jeff Sharkey2018-06-291-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an app starts becoming Direct Boot aware, it can be difficult to track down all the places they're reading data from credential protected storage. When a user is locked, credential protected storage is unavailable, and files stored in these locations appear to not exist, which can result in subtle app bugs if they assume default behaviors or empty states. Instead, apps should store data needed while a user is locked under device protected storage areas. Bug: 110413274 Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java Change-Id: Ia390318efa6fefda8f10ac684d0206e67aa1d3dc
* | Get android.os tests running against real APIs.Jeff Sharkey2018-06-291-5/+3
|/ | | | | | | | | Combination of moving to existing public API, tagging things as @TestApi, and bringing utility methods into tests. Bug: 13282254 Test: atest cts/tests/tests/os/ Change-Id: Ifd24c0d048d200e8595e194890cc1dc53ddc2b3e
* Give StrictMode more bits to work with.Jeff Sharkey2018-06-261-319/+212
| | | | | | | | | | | | | | We're almost out of bits, and we don't really need to smash both thread and VM policy into the same 32-bit value, so use the lower 16-bits for each policy type and the upper 16-bits for penalty. ActivityManager is only consulting the penalty bits, so we can remove getViolationBit() and switch CTS over to doing instanceof checks. Bug: 110413274 Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java Change-Id: I760e6a28f56da66dc75b7df9daf2167ff5bdff50
* StrictMode to catch implicit Direct Boot matching.Jeff Sharkey2018-06-261-1/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | When an app starts becoming Direct Boot aware, it can be difficult to track down all the places they're implicitly relying on PackageManager filtering behavior. For example, if the current Launcher isn't Direct Boot aware, we hide it until the user is unlocked, which could confuse other Direct Boot aware apps into thinking it had been uninstalled, which could cause data loss. This change helps apps track down places where they're implicitly relying on the automatic filtering; they should instead carefully choose a combination of MATCH_DIRECT_BOOT flags to decide on the explicit matching behavior they want. To implement this, we partially migrate the updateFlags() methods out into ApplicationPackageManager, since the checking needs to happen on the client side to correctly report StrictMode violations. We don't currently mutate the flags, but we retain the naming to keep that door open in the future. Test: manual Bug: 110413274 Change-Id: Iff6feba19da81ea1b4eeb3af821c3bdfbd9bf17c
* Merge "StrictMode: fix non-SDK API usage detection." into pi-devMathew Inwood2018-04-201-0/+6
|\ | | | | | | | | | | am: c72ee1a4f2 Change-Id: If0db894c3cb9660eb187280cda21423866387799
| * StrictMode: fix non-SDK API usage detection.Mathew Inwood2018-04-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | The warning dedupe logic in the runtime meant that only the first usage of each API was detected. Disable this logic when DETECT_VM_NON_SDK_API_USAGE is enabled. Test: m Test: $ atest android.os.cts.StrictModeTest#testNonSdkApiUsage Bug: 78268765 Change-Id: Iba1127b84180b9a5e5eb68abc4691ccad082b80e
* | resolve merge conflicts of c8f5480981f987cb40989f387deeea360670f018 to ↵Narayan Kamath2018-04-051-1/+43
|\| | | | | | | | | | | | | pi-dev-plus-aosp Test: I solemnly swear I tested this conflict resolution. Change-Id: I0aa2671c54b0af4a6104e52aea0b5474922042fe
| * StrictMode: Add support for warning on non SDK API usage.Narayan Kamath2018-04-031-1/+43
| | | | | | | | | | | | | | | | | | | | Adds new API methods to enable and disable these warnings. Bug: 73896556 Test: StrictModeTest Change-Id: I049812fcdc79f191ab627766f66fc6f51b82e3d1 Merged-In: I096ce4c355c79cde1b98c3f48d392cd0b2ea5d98
* | Add new 'explicit GC' policy to StrictMode.Pete Gillin2018-03-081-1/+42
|/ | | | | | | | | | | | | | | | | This change adds the policy but offers no public way to enable it. A follow-up change will expose the detect/permit methods in the API and change detectAll to enable it. This new policy can only be triggered through the libcore BlockGuard API. Bug: 3400644 Test: cts-tradefed run cts-dev -m CtsLibcoreTestCases Test: cts-tradefed run cts-dev -m CtsOsTestCases (cherry picked from commit c92f9edf53d09952fe9ab3d8066aed7fa7ecc852) Change-Id: Ieebe4db747902246968d6382bbc9cee0e539af85 Merged-In: Ieebe4db747902246968d6382bbc9cee0e539af85 (cherry picked from commit b3b0731241d9892895045788cb864ec4a4d89212)
* Pass forward listeners when using existing builderKurt Nelson2018-02-271-0/+2
| | | | | | | | | | This is how VmPolicy behaves. Bug: 62458446 Test: cts-tradefed run commandAndExit cts-dev --module CtsOsTestCases --test android.os.cts.StrictModeTest Change-Id: Iccab728bf21bad695f26891042dfe355506cdc5c
* Flip order of argumentsKurt Nelson2018-02-231-2/+14
| | | | | | | | Callbacks as the second parameter is more Kotlin friendly. Bug: 73751206 Test: cts-tradefed run commandAndExit cts-dev --module CtsOsTestCases --test android.os.cts.StrictModeTest Change-Id: Ib9c9469be1b81dc65e74c9e303f474c54a43b18b
* Show Extensible StrictMode APIsKurt Nelson2017-11-091-13/+3
| | | | | | Bug: 63535923 Test: none Change-Id: I07382eae70292c6a78fff9eced26dd1916bc783c
* Extensible StrictModeKurt Nelson2017-11-091-81/+226
| | | | | | | | | go/extensible-strictmode for design doc. Bug: 63535923 Change-Id: Ic5c48fc06d2167dc99b86e264e114a9af49f12a1 Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest
* Consistent handleApplicationStrictModeViolation.Jeff Sharkey2017-11-061-70/+38
| | | | | | | | | | Factor out the logic that calls into ActivityManager, since we have some evidence of violations being triggering before AM has been published. Test: manual Bug: 68940916 Change-Id: Ie64b1eea42393089a657a9b5ae0c4585a0c83bfa
* Flip feature flag to enable StrictMode defaults.Jeff Sharkey2017-11-031-1/+1
| | | | | | Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest Bug: 68662870 Change-Id: I61178def217521ad413074ece3482f4e60428506
* Narrower StrictMode defaults.Jeff Sharkey2017-11-031-83/+129
| | | | | | | | | | | | | | | | | | | | | | | | | Until now, userdebug and eng builds have tracked StrictMode violations on all system apps, including prebuilts that we have no control over, which results in a lot of unactionable noise. This CL narrows the set of enabled apps to only "bundled" system apps, which gives us a much higher chance of burning these violations down to 0 and keeping them there. We don't have a good proxy for an app being "bundled", so we detect it based on being in the "android." or "com.android." package namespace. Clean up the entire flow of applying StrictMode defaults to make it much more human-readable. This resulted in us fixing a bug where StrictMode was never actually enabled for jank-sensitive threads in system_server! Relax I/O checks in a few places where we know we're interacting with procfs or sysfs. Add internal "allow" methods that avoid object allocation by returning raw mask. Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest Bug: 68662870 Change-Id: I536e8934fbcdec14915fcb10995fc9704ea98b29
* Structure StrictMode violations as ThrowablesKurt Nelson2017-11-031-234/+127
| | | | | | | | | | | | | | | | | | | | | | | | All violations of StrictMode now inherit from one central Violation class. This unlocks adding penaltyCallback(Violation). Parsing strings is no longer required to infer what type of violation something is. Violation classes have no need to be loaded in Zygote as only developers opt-in to this feature and will see violations. Cross-binder thread violation perf test: before 2872331 2574093 2481208 after 1938227 1742714 2654538 Bug: 64258734 Test: cts-tradefed run cts-dev --module CtsOsTestCases --test android.os.cts.StrictModeTest Change-Id: I1971feb03ff77cf297c940cacee62fadb5b8422c
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-12 10:54:09 +0000