summaryrefslogtreecommitdiff
path: root/core/java/android/os/BaseBundle.java
Commit message (Collapse)AuthorAgeFilesLines
* BaseBundle: fix unparcel error logicSteven Moreland2025-07-081-2/+7
| | | | | | | | | | | This code considered a success case to be an unsuccessful case. Bug: 373357090 Test: repro in bug no longer works (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:1997a76a8846a5d5cd27472976885bed0180a59c) Merged-In: Id423936872cbb0e0265ccf2855092357cb175d47 Change-Id: Id423936872cbb0e0265ccf2855092357cb175d47
* Update BaseBundle to not use LazyValues when using ReadWriteHelperHani Kazmi2022-09-251-2/+4
| | | | | | | | | | | | | | | | | This is a partial backport of ag/19532036. It fixes a bug where a LazyValue might have been pointing to a parcel which was already recycled. Bug: 240138318 Test: atest android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest android.os.BundleRecylingTest Test: Running PoC app from linked bug Change-Id: I3acf7127fdf373ee8b38a55702ae315be499601c Merged-In: I8a878a6d0055b04b2611909b4b17977ba5677a4f (cherry picked from commit d2f9cc6342141cdb39f08a229d548d7b29cadd86) Merged-In: I3acf7127fdf373ee8b38a55702ae315be499601c
* BaseBundle.java: Recycle underlying parcel when bundle is cleared.Hani Kazmi2022-06-141-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lazy Bundles, (aosp/1787847), introduced a change in behavior where a Parcel created as part of initializing a Bundle is dependent on the next ART GC run to be recycled, causing a short term memory-leak. To land this in T, we are making the change targetted and allowing consumers to opt into the parcel being immediately cleared by calling .clear() on the bundle. As part of the unparcel() in clear(), mParcelledData is set to null, and mMap may or may not still contain references through lazy values, depending on if the lazy valyes have been unmarshalled. As such, we keep a weak reference to mParcelledData we can use to recycle it. The mParcelledData reference could have been copied to other bundles in a few operations: new Bundle(Bundle o) bundle.deepCopy() bundle.putAll() In this case we can not recycle the parcel yet as other bundles may still require it. If so, we will skip the recycle and rely on the later GC pass Bug: 233216232 Test: Reproduced linked bug on-device Test: atest android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Change-Id: Ic26eceaa1c11da67866af0963f760423d41d54bc
* Adjust Class<T> parameter bounds in new Bundle APIsBernardo Rufino2022-03-011-1/+1
| | | | | | | | | | So they are consistent with Parcel and allow for patterns where the client specifies a more narrow type to perform the check while returning or populating a list of a broader type. Test: atest -d android.os.cts.BundleTest Bug: b/220872166#comment3 Change-Id: Ie0d430bb0ecd7fe4ee4bbbd245e38ff2813cc4eb
* Add safer Bundle APIs and deprecated old onesBernardo Rufino2022-02-191-44/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add safer Bundle APIs that take an extra Class<T> argument that checks that the type about to be deserialized is a child of the type passed in parameter *before* actually deserializing it, while also deprecating old APIs. This allows use to reap the benefits of the new typed Parcel APIs and enhances security. Only the APIs that could involve custom object injection are modified. So, besides the obvious ones that have that design (eg. readParcelableList()), subtler cases such as readIntegerArrayList() could result in custom object deserialization, and since it's all generics, even the casting inside Bundle wouldn't fail, only after the client unpacked the list items would it blow up. Now those are checked beforehand. Since Bundle always calls Parcel.readValue() under the hood (instead of specialized APIs such as readParcelable() etc), we had to augment that method (that's used by LazyValue when retrieving the item) to accept item types now for containers, which I implemented as a vararg of Class<?> parameters (this is all private/@hide). This way we could retrieve a list of intents like readValue(.., List.class, Intent.class), or a map of string to intents like readValue(.., Map.class, String.class, Intent.class). For non-container items, we can just pass no arguments for the vararg. This is explained in internal javadocs. Inside readValue() now, we also check the container types before calling the internal methods for deserialization. So, if the thing on the wire is a VAL_MAP and we know the method we're about to call will return a HashMap, we verify that the type passed in parameter is a super type of that (if it's non-null, if it's null it means "perform no check"). Now, LazyValue became a BiFunction<Class<?>, Class<?>[], Object> to receive those extra "item types" for containers. The reason for separating the first from the rest is that the first defines the return type in the new APIs and inside Parcel, so we need the T from Class<T> to ensure type-safety. (I was torn here between using BiFunction or just exposing LazyValue as @hide for Bundle since it feels like we're missing meaning/abstraction, but end up leaving this way, advise if you'd prefer the other way) There was a bit of a refactor in Parcel so readValue() could call internal methods that accepted nullable Class<?> parameters with the meaning that null = "no verification" and non-null = "check against type provided" (because the external APIs all require non-null parameters). Now we can return null in all cases when there is a type mismatch. Note that the Bundle APIs catch ClassCastException to return null, but that only works for non-generic types (eg. getSizeF()). For generic types wrapping "return (T) o" with try-catch doesn't work because the type gets erased to its bound at runtime, so the type mismatch escapes that try-catch to the caller, potentially causing a crash. Now they happen inside the getters, as the non-generic ones. Test: Boots for now Test: Working on CTS Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest CTS-Coverage-Bug: 219980813 Change-Id: Ifcbeb34b4684d7de105756b9d414162a9205ffaa
* Add @hide Bundle.getParcelable() with explicit typeBernardo Rufino2022-02-161-18/+34
| | | | | | | | | | | | | Provider a type-safer API getParcelable() that takes a Class<?> parameter. Test: Manual (tested downstream) Bug: 213169612 Bug: 212804042 Bug: 212803946 Bug: 210885162 Merged-In: Ieebc044043e0776e71d35c1cc11be9299f972c45 Change-Id: I76f9558bfa1525877bec15cfc43abdc43cba0f24
* Refactor Bundle for thread-safety of Bundle.hasFileDescriptors()Bernardo Rufino2021-11-021-47/+53
| | | | | | | | | | | | | | | | | | After aosp/1878338, I realized Bundle.hasFileDescriptors() was accessing mParcelledData and mMap without a lock. So, to avoid locking there, I made mParcelledData volatile (since after mParcelledData is null, it can never be non-null again and mMap is guaranteed to be non-null). So, moved assignments to mParcelledData to be last wrt mMap and mParcelledByNative to ensure visibility of those fields. While refactoring copyInternal(), realized that method was always used after constructing an uninitialized Bundle, so to avoid mistakes with objects not properly initialized, I created a constructor in Bundle, PersistableBundle & BaseBundle that does that copyInternal() did. Bug: 195622897 Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Change-Id: I5c9337496da7ecf87f10370726099dcb247a6789
* Merge "Avoid full unparcelling where possible in Bundle"Treehugger Robot2021-10-061-4/+12
|\
| * Avoid full unparcelling where possible in BundleBernardo Rufino2021-10-051-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and put a warning where it's not possible. This is to make sure we know when to touch bundles provided by apps. In this CL: * deepCopy() now doesn't deserialize lazy objects before copying. It doesn't copy them either, it merely passes them into the new map as the same reference. This works because we implemented fine-grained locking into each lazy value, so concurrent access won't be a problem. Furthermore, LazyValue caches the deserialized object, so we'd still honor the contract of deepCopy() that "Other types of objects (such as Parcelable or Serializable) are referenced as-is and not copied in any way". I had to perform one extra check in the synchronized block in LazyValue to guarantee this (double-checked locking), I explain that in the comments. * Removed filterValues() and codepaths that used it. This was created with the purpose of removing items whose classes weren't available to the system to prevent crashes coming from full deserialization. This is not a concern anymore with lazy bundle, hence we can remove the codepaths altogether (see email for more details). * Put warnings in javadoc of getMap() and PeristableBundle(). Test: Boots Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Bug: 195622897 Change-Id: I14bb6a7874814f42cbcc6b5fd372c42752aa74c8
* | Change defusing for lazy bundlesBernardo Rufino2021-10-051-18/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With lazy bundle, exceptions thrown by deserialization of custom items moved from being thrown in initializeFromParcelLocked() (when the bundle is first touched) to being thrown in getValueAt() (whenever the item is retrieved), which means they were escaping the defuse logic that caught those exceptions. So, now also catching these exceptions in getValueAt(), however, here we can be much less drastic, instead of erasing the bundle, we can simply remove the bad element. This also means we don't need to log wtf in initializeFromParcelLocked() if sShouldDefuse = true but the bundle is not marked as defusable, since touching the bundle doesn't carry the same consequences as before go/lazy-bundle. So, I moved that log to unparcel(itemwise = true), ie. whenever the entire bundle is deserialized on purpose. Now, 2 types of defusing can happen: 1. If the (custom) item we're retrieving caused the exception, we'll remove the item and return null. 2. If the exception was raised during partial deserialization, that is, during the read of the map and its basic types (while skipping custom types), the map will be left empty. I believe only manually written parcels would cause this type of exception and if an exception is raised here it will also be raised in the final destination too, afaict. Because of this, we can now touch app-provided bundles without fear of clobbering the data on its way to the final destination. Following conversation on previous CL, narrowed exception raised in case of unknown type to be BadParcelableException. Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Bug: 195622897 Change-Id: I4746140f63482a9ea475aac25897a447737393e4
* | Correct Parcel value typesBernardo Rufino2021-10-011-4/+4
|/ | | | | | | | | | | | | | | | | | * Bundle supports types char, char[], short[], float[] which were falling back to serializable handling in Parcel because readValue() didn't have specific support for those types. Adding support in Parcel to avoid the need for length-prefixing and to improve performance. Curiously some of those had read/write methods already. * Updated Bundle to just pull the types above from the map since those won't be lazy values anymore. * We were missing a few custom type containers in our list of length-prefixed types and we were listing Bundle unnecessarily as length-prefixed since Bundle itself is already length-prefixed and copies the correspondent section of the parcel internally. Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Bug: 195622897 Change-Id: I1e15d59d883311685ffa32ece1f5a00e01bf6aea
* Log.wtf in mismatch + testsBernardo Rufino2021-09-291-1/+1
| | | | | | | | | Log mismatches as wtf to be able track those. Also added unit tests around kindofEquals() and r/w mismatches. Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Bug: 195622897 Change-Id: I361dd144b23975eedc8b19ed65457a1c5405936e
* Synchronize in LazyValue.get()Bernardo Rufino2021-09-221-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we use Bundle's copy constructor we perform a shallow copy of the underlying map, so lazy values are the same across the original and the clone. So, if we're accessing the same item backed by a lazy value in 2 different threads, each one accessing a different bundle (the original and the clone), both would have to synchronize on a common lock. Although Bundle is not thread-safe, we should keep the expectation that the client only needs to properly synchronize access to one bundle, not more. To achieve this, we synchronize on the original parcel held by LazyValue in get(), this removes the need for the above. Note that after we produce the lazy values and put them in the map, we don't have a reference to mParcelledData anymore inside the Bundle, the only objects holding a reference to that parcel are the lazy values. Also fixed some stuff in LazyValue: * Fixed condition inside LazyValue that used mObject == null as signal for "not deserialized" state since mObject can be null, so switched to mSource != null. * Made mSource volatile and adjusted operations to always check it before, ensuring visibility of itself and mObject via happens-before. This works because after checking mSource, if that's null, mObject is guaranteed to be visible and valid, if it's not null, we can use it since we're in the serialized state and this works even if another thread deserializes in between as long as we hold on to a reference of mSource in a local because the parcel is still valid. * Remove the recycling of mValueParcel, otherwise we'd need locking to ensure whatever was using it was still using a valid object. Decided to just remove recycling for now since the plan is to remove mValueParcel entirely when we add comparison and hasFileDescriptor() methods that operate on a range to Parcel. Bug: 195622897 Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Test: More tests coming Change-Id: I501c91f505950338b23e7837e55f89b2f63ff93a
* Lazy bundleBernardo Rufino2021-08-271-28/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement lazy deserialization for custom types in bundle: * Parcelable (VAL_PARCELABLE) * Serializable (VAL_SERIALIZABLE) * Parcelable array (VAL_PARCELABLEARRAY) * Lists (VAL_LIST) * Sparse array (VAL_SPARSEARRAY) * Bundle (VAL_BUNDLE) This enhances security, makes bundles more robust to deserialization errors and avoid deserializing unneeded objects in some cases*, for more details check go/lazy-bundle. To do that, we prefix those types with their length when writing them on the wire. Map serialization and deserialization now happens inside Bundle (instead of calling Parcel's readArrayMapInternal() / writeArrayMapInternal()) and we use an intermediary object - LazyValue - that holds information about the position and length of the value we will deserialize when queried. So, there are basically 3 states: 1. We received the bundle but haven't queried anything about it (not even isEmpty()): in this case the original parcel is held inside and we haven't attempted any deserialization (except for the metadata at the beginning such as the magic, etc) 2. We queried something on it (eg. isEmpty()): Now we deserialize the bundle skipping the custom values above (we're able to do this now with the length written on the wire) and instead placing LazyValue objects for them in the map. 3. We query one of the lazy values: Now, we deserialize the object represented by LazyValue and replace it on the map. Since after (2) LazyValue objects are the only ones holding references to the original Parcel, when all LazyValues are deserialized, the original Parcel is available for GC. Inside bundle now we differentiate between unparcel(itemwise = true) and unparcel(itemwise = false) where the first also deserializes each item (such that there are no LazyValues in the map). This is because some operations such as kindofEquals() need all items deserialized. I had to break a few methods in parcel into multiple methods in parcel to be able to control the format in bundle. They are all @hide. * In quick local experiments, counting the bytes that didn't need to be deserialized after the change. Roughly 10% of bytes from custom-type items in Bundle are not deserialized in the testing scenario (if I haven't messed up the stats :). That's on a sdk_gphone_x86_64_arm64 a few minutes after boot. Check https://screenshot.googleplex.com/53uXrrqDMYahzg3, stats collection is on ag/15403076. Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest Test: Boot device Bug: 195622897 Change-Id: Icfe8880cad00c3cd2afcbe4b92400ad4579e680e
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-11-041-1/+1
| | | | | | | | | | | 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 Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
* 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
* Improve BaseBundle#kindofEqualsSuprabh Shukla2020-02-141-1/+8
| | | | | | | | | | If both BaseBundles are empty, we can infer that without needing to unparcel any of them. Test: atest FrameworksCoreTests:android.os.BundleTest Bug: 146037505 Change-Id: I04c28cdd1293227d9887b0c17e178f61328c1959
* 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
* Expand ContentProviderOperation to support call().Jeff Sharkey2019-08-081-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | ContentProviderOperation has long supported basic operations like insert(), update(), and delete(), but it was never extended to support the general-purpose call() method. This change adds support for call(), including configuration of the extras Bundle using back-references to other operations. In addition, the output Bundle from call() can be used for back-references from other operations. Clean up how back-references are handled internally; we now store either a literal value in each slot, or an explicit BackReference instance which we can "instanceof" check to resolve when needed. Also add withExceptionAllowed() capability, which can be used to catch and report the failure of a single operation while allowing any subsequent operations to proceed. Adds various nullability annotations to reflect the behavior of all existing logic. Bug: 131598520 Test: atest android.content.cts.ContentProviderOperationTest Test: atest android.content.cts.ContentProviderResultTest Change-Id: I1744bf8fc1ad048aa96460d487c2867c4c81d7b3
* Add @UnsupportedAppUsage annotationsAndrei Onea2019-03-151-0/+5
| | | | | | | | | | | | | | | | 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
* Check Bundle length is aligned by 4 when readFromParcel.Hui Yu2018-09-121-1/+2
| | | | | | | | Otherwise throw an IllegalStateException. Fix: 26885514 Test: Make the bundle length not aligned by 4 and observe the IllegalStateException. Change-Id: I57f0d5babdf1b8f1074eb2f4f76b71926db8b93c
* Fix PersistableBundle C++ -> Java interopMakoto Onuki2018-04-261-8/+32
| | | | | | | | | | | | | PersistableBundle.java expects items to be sorted by the hash codes of the keys, but PersistableBundle.cpp isn't compatible to it. PersistableBundle.java now knowns what was parceled by C++ because it now uses a different magic, and change the unpercel strategy. Change-Id: Ia516f80b6d48dcb9f981767e0e64303434f39fb4 Fixes: 65744965 Test: adb shell sm fstrim and check logcat
* APIs to suspend packages with SUSPEND_APPS permissionSuprabh Shukla2018-03-221-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed the existing hidden api setPackagesSuspendedAsUser to a system api setPackagesSuspended that can be called by apps with either MANAGE_USERS or SUSPEND_APPS permission. Additionally, the suspending app can now specify optional extra information meant to be used by the suspended apps and the launcher to deal with this state. The following other APIs are added: - isPackageSuspended(): Apps can query whether they are in a suspended state - @SystemApi getPackageSuspendedAppExtras(String): Apps with permission SUSPEND_APPS can get the appExtras passed to PM when suspending the app. - @SystemApi setPackageSuspendedAppExtras(String, PersistableBundle): Apps with permission SUSPEND_APPS can update app extras for a suspended package. - getPackageSuspendedAppExtras(): Apps can call to get the appExtras passed in to PM when they were suspended. Test: Can be run via: atest com.android.server.pm.PackageManagerSettingsTests atest com.android.server.pm.PackageUserStateTest atest com.android.server.pm.SuspendPackagesTest Bug: 74336673 Change-Id: I3b9ed2c8478b34ee2e8986f5f5fddb2839d102e3
* Reduce duplicate strings due to the package cache.Makoto Onuki2017-08-041-46/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change from the previous attempt: - Fixed the helper class. The original version had a few bugs. - Bundle.readFromParcel() now handles a Parcel with a read-write helper properly. ** Comparison ** The following charts are the actual measurement with and without the fix, using "dumpsys system". - The red bar is "total private dirty". - The X axsis is time since boot. Without fix: - #1 First boot: -- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=1971317391 -- Private dirty stabilizes at ~16.8M. -- Loading system packages took 1.8 seconds. - #2 Second boot: -- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=982210726 -- Private dirty stabilizes at ~17.5M. -- Loading system packages took 0.5 seconds. With fix: - #3 First boot: -- https://docs.google.com/spreadsheets/d/1R6lL0AnAp93HnrqWujJFNgOjj6wvGicgDlbDAevbc3g/edit#gid=791764875 -- Private dirty stabilizes at around the same level as #1. -- Loading system packages took 1.9 seconds. - #4 Second boot: -- https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=1820894299 -- Private dirty stabilizes at around the same level as #1. -- Loading system packages took 0.7 seconds. Package manager start up time with and without the fix: - (Ignored ones that are too fast; probably the thermal throttling didn't kick in.) - https://docs.google.com/spreadsheets/d/1CbmU8cQQQw7n7tyqbZi3beRHNuzqcmJgdvzDpi40Q1I/edit#gid=499396796 - Before: 3.5 seconds (average of 5 reboots) - After: 3.6 seconds (average of 5 reboots) Package scan speed comparison: - With the fix, first boot. 08-03 08:49:56.851 1000 779 779 I PackageManager: Finished scanning system apps. Time: 2133 ms, packageCount: 143 , timePerPackage: 14 , cached: 0 08-03 08:49:56.971 1000 779 779 I PackageManager: Finished scanning non-system apps. Time: 121 ms, packageCount: 11 , timePerPackage: 11 , cached: 0 - With the fix, second boot. 08-03 08:53:29.387 1000 779 779 I PackageManager: Finished scanning system apps. Time: 484 ms, packageCount: 143 , timePerPackage: 3 , cached: 143 08-03 08:53:29.424 1000 779 779 I PackageManager: Finished scanning non-system apps. Time: 37 ms, packageCount: 11 , timePerPackage: 3 , cached: 11 ** Conclusion ** - This CL wil slightly slow down the boot time (0.2 seconds on a thermal-throttled bullhead), but the system server's ram consumption will go down to the no-cache level. - Using the package cache is still faster than not using it. Test: build, boot, reboot, adb-install, reboot Test: bit FrameworksCoreTests:android.content.pm.PackageParserTest Test: bit FrameworksServicesTests:com.android.server.pm.PackageParserTest Test: cts-tradefed run cts-dev --skip-device-info --skip-preconditions --skip-system-status-check com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker -a armeabi-v7a -l INFO -m CtsOsTestCases -t android.os.cts.BundleTest Bug: 64112468 Change-Id: I30691a032cb1dd1c7f6c1966a096c2f0d07a09cb
* Log Bundle statistics when too large.Jeff Sharkey2017-07-051-0/+48
| | | | | | | | | | When we have trouble pushing a saved instance state Bundle out of a process, log high-level statistics to help narrow down where bloat is coming from. Bug: 62409379 Test: builds, boots, stats logged Change-Id: Iaff01eaf31ff0fd4d0fde3da15e9526dac559af9
* Fix issue #37360626: Apps can schedule alarms (and other things) with temp ↵Dianne Hackborn2017-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | whitelist There is now an IBinder "token" that must be specified when setting the whitelist duration for an Intent. To have the whitelist supplied, the caller to send a PendingIntent must pass in the same token. The PendingIntent and IntentSender classes now internally maintain this token to pass in when their send() is called. The big complexity for making this work is we now need to associate this whitelist token correctly with the actual PendingIntent objects that applications and other code is getting. To do this, we propagate the token in the Notification object, and have a new API on Parcel that allows us to make it available to PendingIntent when it is unmarshalled. And this allows to deal with PendingIntents appearing in nested bundles, as we can propagate that information from the original Parcel to the new Parcel that Bundle keeps to delay unmarshalling. Test: manual Change-Id: Idda00490ccfe2be37e4ab21354b9ab7528a52750
* Add new "work queue" feature to JobScheduler.Dianne Hackborn2017-04-111-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gives semantics similar to the start command queue of services. The implementation is currently lacking in URI permission grant handling of the work intents; that will be coming in a follow-up change. This includes a first step of adjusting/fixing locking within JobSchedulerService. The JobServiceContext class has a bunch of stuff it does that assumes it doesn't need locking because it schedules the work on a handler. However, to be able to correctly implement the work finish flow (that takes care of stopping the job when there is no more work), we can't dispatch these asynchronously so need to get rid of that and just do explicit locking. The switch to explicit locking is half-way there (again the remaining part will be a follow-on CL). Right now we have the locking, but still also the handler. But it turns out there were a number of things we were doing without a lock held where we actually should have been holding a lock, so this is better anyway. Test: new tests added Change-Id: Iebd098046209b28e60fd2f4d855d7f91cd3a8b03
* Implement issue #36590595: Add ability to associated a ClipData with JobInfoDianne Hackborn2017-03-311-0/+14
| | | | | | | | | | | Yum! Also needed to have a Context.revokeUriPermission() variant that is sane, so reasonable CTS tests can be written. Test: new ClipDataJobTest added. Change-Id: Ia3135ea788a6e32c971bae7dab3a844d0ef4139c
* Fix issue #35813125: API Review: android.os > BundleDianne Hackborn2017-03-031-5/+5
| | | | | | | | | - Renamed deepcopy to deepCopy. - Clarified docs about when a shallow vs. deep copy happens. Test: booted and ran Change-Id: I2b4400770d781ff51423cd1c860454742e1d3c9c
* Fix for race in writeToParcel and unparcelAmith Yamasani2016-12-161-52/+58
| | | | | | | | | | | | Don't access the parcelled data while it might be recycled by another thread. Also make a local reference of mMap, which could be modified by another thread. Bug: 33325384 Test: Hard to repro, so no test Change-Id: I77f6545ac174236a3da69c0c0f3a01b2eda3f34b
* resolve merge conflicts of a14aac9 to masterDianne Hackborn2016-05-041-46/+56
|\ | | | | | | Change-Id: If92c42a9e6fbc3cccd24fa2677f0e4c34d65c923
| * Maybe fix issue #28457907: Pebble app crash + rebootDianne Hackborn2016-05-041-47/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | Fix this long-standing multi-threading issue in Bundle when multiple threads are trying to read from a Bundle and conflict to due unparceling. There are two critical sections this protects: writing the bundle in to a parcel (when it is doing this from the bundle's already parcelled representation), and unparcelling a bundle into its map of entries. Change-Id: I5470002f090e63dd623a573da6c204d3b5b661f4
* | resolve merge conflicts of 7983723 to masterAndreas Gampe2016-04-201-9/+17
|\| | | | | | | Change-Id: I1e903d23598c8066b9103499287a7ee04d33c75a
| * Frameworks/base: Add holder to BaseBundleAndreas Gampe2016-04-191-9/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Move EMPTY_PARCEL into an inner holder class. Add holder to preloaded-classes. Clean up dependencies. Allows to compile-time initialize: * android.os.BaseBundle * android.os.Bundle * android.os.PersistableBundle * android.telephony.CarrierConfigManager Bug: 27265238 Change-Id: Ib8017aa419c2985963b3c68a8046462a38652ef2
* | Merge "Disable "defusable" logging for now." into nyc-dev am: d3a25ad am: ↵Jeff Sharkey2016-04-191-1/+3
|\| | | | | | | | | | | | | | | | | | | | | ea54db6 am: df6d014 * commit 'df6d01463adf4b96bdd4dc317ac7b479bb2bc0d4': Disable "defusable" logging for now. Change-Id: I6458200608363a58c8a769fdcc4d309bb4e8de91
| * Disable "defusable" logging for now.Jeff Sharkey2016-04-181-1/+3
| | | | | | | | | | Bug: 28240784 Change-Id: I2c259867a8169eef220fb9faea6cdcafdde675b8
* | Merge "Fix a deadlock due to wtf in BaseBundle" into nyc-dev am: 27c49d5Amith Yamasani2016-03-311-1/+2
|\| | | | | | | | | | | | | | | | | am: 54ef247 * commit '54ef24779fee7060c3da52e8973a3e1240ac3d10': Fix a deadlock due to wtf in BaseBundle Change-Id: I739db48b3133ff963a786bb9b00aa8f842883ef8
| * Fix a deadlock due to wtf in BaseBundleAmith Yamasani2016-03-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | Use Slog.wtf instead of Log.wtf, so that it is asynchronously reported. Mark incoming application restrictions as defusable since they are being unparceled. Bug: 27811728 Change-Id: I166de69a74417e439ec5ef9159fbbfbfe711dde6
* | Merge "Defuse Bundles parsed by the system process." into nyc-dev am: c4b0adeJeff Sharkey2016-03-171-6/+51
|\| | | | | | | | | | | | | am: a0f6318 * commit 'a0f6318f44244ec4e916d3abecf157beb4fefc8c': Defuse Bundles parsed by the system process.
| * Defuse Bundles parsed by the system process.Jeff Sharkey2016-03-161-6/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's easy for apps to throw custom Parcelables into Bundles, but if the system tries peeking inside one of these Bundles, it triggers a BadParcelableException. If that Bundle was passed away from the Binder thread that delivered it into the system, we end up with a nasty runtime restart. This change mitigates this trouble by "defusing" any Bundles parsed by the system server. That is, if it encounters BadParcelableException while unpacking a Bundle, it logs and delivers an empty Bundle as the result. Simultaneously, to help catch the system process sticking its fingers into Bundles that are destined for other processes, a Bundle now tracks if it's "defusable." For example, any Intents delivered through ActivityThread are marked as being defusable, since they've arrived at their final destination. Any other Bundles are considered to be "in transit" and we log if the system tries unparceling them. Merges several Parcel boolean fields into a flags int. Add better docs to several classes. Bug: 27581063 Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
* | resolve merge conflicts of 1ca3800c44 to masterMakoto Onuki2016-03-081-0/+6
|\| | | | | | | Change-Id: I4657cdf99900cd555c3109605e8cbdbb0fed79e6
| * Introducing ShortcutManagerMakoto Onuki2016-03-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | What's supported: - Most APIs are implemented, except for SM.updateShortcuts(), the icon APIs in LA, and LA.startShortcut(). - Persisting information, except for icons - Throttling In addition, now PersistableBundle has a public copy constructor from a Bundle. (Do we want to @hide it?) TODOs: - Add icon support - Implement missing APIs - Listen to PACKAGE_* broadcasts and do clean-up - Support multi-launcher apps (pinned shortcuts per launcher) - Dev option to reset throttling - Load throttling config from Settings - Backup & restore - Figure out LauncherApps permissions (BIND_APPWIDGETS??) - Other minor TODOs in the code - Better javadoc Note: This requires Idf2f9ae816e1f3d822a6286a4cf738c14e29a45e Bug 27325877 Change-Id: Ia5aa555a4759df5f79a859338f1dc5e624cd0e35
* | Implement transient extras for jobs.Dianne Hackborn2016-02-111-18/+78
|/ | | | | | | | | You can now associate an arbitrary Bundle of extras with a job, as long as the job is not persisted. Also implement deep-copy of Bundle. Change-Id: I7890d627492b664d9b1f039e8cb82f8868de7be3
* Merge "Add comments to keep Java and native binder PersistableBundle in ↵Samuel Tan2015-12-171-0/+6
|\ | | | | | | | | | | | | | | | | sync" am: 6de926a7d6 am: 4981ae9083 * commit '4981ae908349767fee7976cc82c54a7fb00ee4fd': Add comments to keep Java and native binder PersistableBundle in sync
| * Add comments to keep Java and native binder PersistableBundle in syncSamuel Tan2015-12-151-0/+6
| | | | | | | | | | | | | | | | | | Add comments stating that certain methods of the Java binder framework should be kept in sync with the corresponding methods mirrored in the native PersistableBundle implementation. BUG: 25815410 Change-Id: I475b2e9a527291eea58c8178cd733c444dfcfed5
* | Fix security issues when using Parcel.setDataPosition() with untrusted inputAdam Lesinski2015-10-011-5/+7
|/ | | | | | | | When seeking forward in the Parcel, adding the extracted size to the Parcel.dataPosition() can result in an overflow. Guard against this. Bug:23909429 Change-Id: If37cdebbf05a92810300363d1a6ecd8b42b6da26
* More work on collecting assist data.Dianne Hackborn2015-03-121-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Optimize parceling of AssistData (which is now renamed to AssistStructure) by pooling duplicated class name strings. Change text associated with a view node to a CharSequence, so styling information comes along. Include global text attributes -- size, colors, etc. Introduce a new AssistContent structure, which allows us to propagate information about the intent and data the activity is looking at. This further allows us to propagate permission grants, so the assistant can dig in to that data. The default implementation propagates the base intent of an activity, so if for example you bring up the assistant while doing a share the assistant itself has the same information and access that was given to the share activity (so it could for example share it in another way if it wanted to). Did some optimization of loading PersistableBundle from xml, to avoid duplicating hash maps and such. Changed how we dispatch ACTION_ASSIST to no longer include the more detailed AssistStructure (and new AssistContent) data when launching; now the example code that intercepts that needs to be sure to ask for assist data when it starts its session. This is more like it will finally be, and allows us to get to the UI more quickly. Change-Id: I88420a55761bf48d34ce3013e81bd96a0e087637
* Annotate Bundle with @NullableScott Kennedy2015-03-011-46/+64
| | | | Change-Id: Ide572124deea8271ca5c47009acb62603d644363
* Add put/getBoolean/Array to PersistableBundleCraig Mautner2014-12-091-5/+5
| | | | | | | | | | Due to popular demand the methods putBoolean(), getBoolean(), putBooleanArray() and getBooleanArray() have been added to PersistableBundle. Fixes bug 18390436. Change-Id: Id133ba902aca774f98529e36ce560e873b88ad5b
* Update javadoc for android.os.Bundle.Narayan Kamath2014-07-011-4/+8
| | | | | | | | | | | Call out the fact that defaultValue is returned if a null mapping exists for a given key. bug: https://code.google.com/p/android/issues/detail?id=68453 (cherry picked from commit ca2197b0457b1626b95a053d835ceaca43ac0286) Change-Id: Iec70478ae091bb222be6e9ef9726c817395e9e23
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 01:13:16 +0000