summaryrefslogtreecommitdiff
path: root/core/java/android/util/LongSparseArray.java
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Add LongSparseArray.removeIf(Predicate).Sudheer Shanka2020-02-191-0/+15
| | | | | | Fixes: 149648797 Test: atest core/tests/coretests/src/android/util/LongSparseArrayTest.java Change-Id: Ib7e73dcfe8be1dc1f3af577f30da7ebd5950d42a
* Correctly parcel LongSparseArray<String>Philip P. Moltmann2019-10-241-53/+12
| | | | | | | | Before we just cast Object[] to String[]. This crashes. Now we are casting the individual objects->strings. Test: Parceled LongSparseArray Change-Id: I24883a1dad49c0682977da1aea2370eddb001173
* Add feature contextPhilip P. Moltmann2019-10-171-0/+93
| | | | | | | | | | | | | | | Currently only used by app-ops, but can be used by other modules too. AppOps will collect app-ops based on feature. Only the most basic parts of app-ops are supporting features yet. The rest will be added later. Test: atest CtsAppOpsTestCases atest RunSettingsLibRoboTests atest com.android.server.wm.ActivityStarterTests m -j doc-comment-check-docs Bug: 136595429 Change-Id: Ia664f4ff1c1c2ceea721d76dc491ec50c237e9ce
* Add extra comment for implementation.Kweku Adams2019-04-291-0/+4
| | | | | | | | | Add a comment noting that the check to throw the exception is intentionally second so that it's out of the critical path. Bug: 118339123 Test: N/A Change-Id: I36c5ea67579bcd7906f711530392110d9987ffb4
* Gating OutOfBoundsException on targetSdkVersion.Kweku Adams2019-04-261-4/+24
| | | | | | | | | Apps targeting Pie or older will get the old undefined behavior. Apps targeting Q or newer will get the OutOfBoundsException. Bug: 118339123 Test: atest CtsUtilTestCases Change-Id: Ibf5467aadec4a2f76ee180e963afeaf5a8a013a2
* Revert "Revert "Checkng upper bound in *Array classes.""Kweku Adams2019-03-301-3/+16
| | | | | | | | This reverts commit 91ec97056451753d6db55d310fc93fbd93c61cb3. Reason for revert: b/128433495 Change-Id: I4aac43f6aacd594f9c2bf58db9fbc4a1395d8888
* Revert "Checkng upper bound in *Array classes."Paul Scovanner2019-03-121-16/+3
| | | | | | | | This reverts commit 17d453ea85703a5bc26c0669231be4d6f0d8bbac. Reason for revert: b/127750694 Change-Id: I0ffbf0e64109b3ec724e0687a27b231e335f76b4
* Checkng upper bound in *Array classes.Kweku Adams2019-03-051-3/+16
| | | | | | | | | | *Array classes will now throw an IndexOutOfBoundsException if a caller tries to get or set a value for an index that's invalid based on the current size. Bug: 118339123 Test: atest CtsUtilTestCases Change-Id: Iddc9a0c7c89e0ac743b0380049527a1b2dfb434f
* Slice and dice app ops - frameworkSvet Ganov2019-03-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Appops can be peformed by an app on its behalf and also on behalf of another app, i.e. an app can perform a proxy op and blame the work on another app. The proxy mechanims is for apps doing work on behalf of other apps where GCore is one example since the app doing the work needs to check if the caller has access to the functionality - specifically the app op backing a runtime permission in case the calling app does not support runtime permissions. Apps being able to blame work on other apps is a problem now that we would be using historical op data to show permission usage in the UI as apps can start blaming each other to gain a competitive advantage. To address the issue we are adding APIs for querying portions of the app op data - last and historical. One can now get the ops for work the app did for itself, work the app blamed on other apps if the app is trusted, work the app blamed on other apps if the app is not trusted, work other trusted apps blamed on the app, work other untrusted apps blamed on the app. A trusted app is one holding the permisison to update app op stats which is privileged. The data slicing API allow us to show in the UI only the trusted poriton of the data which is work the app did for itself, work trusted apps balmed on the app, and work the app if untrusted blamed on other apps. Test: atest CtsAppOpsTestCases bug:111061782 Change-Id: I9a2bcaea272cb06f38ba742cf601a6dc3b287d5e
* Removing unused method indexOfValueByValueSuprabh Shukla2017-03-241-0/+1
| | | | | | | | | | The method was confusing and not used by anyone. Same functionality can be implemented trivially in the client code. Test: N/A Bug: 35765468 Change-Id: Ia019088cd023c62d83760d9ebe883f7559a43375
* indexOfValue now uses .equals (cont.)Tejas Khorana2016-07-181-2/+31
| | | | | | | | Addresses same issue addressed in SparseArray in LongSparseArray in the method: indexByValue. Made a new method indexByValueByValue that compares objects using .equals instead of ==. Change-Id: I55735fe7ca364d0a9caab2a6909c2eaede845619
* Uses VMRuntime.newUnpaddedArray for ideal array sizesAdam Lesinski2014-03-271-45/+12
| | | | | | Bug:13028925 Change-Id: I0a9301248b10a339afbdc5e4ffe3310ac4fa1fb7
* Fix javadoc typo in SparseArray.Newton Allen2013-11-211-1/+1
| | | | Change-Id: Ie69b2cf96dae95b6ebe7b7797d3755749aec9f35
* Document the order of values returned by keyAt().Flavio Lerda2013-09-081-0/+17
| | | | | | | | | | | The values returned by keyAt() are currently guaranteed to be in ascending order. This is helpful to users of the API to be able to make assumptions about the keys and values when iterating over one of the sparse array implementations. This commit adds documentation about this. Change-Id: I3d7eb78e115ce174f1167b83904b44bf5120b223
* Make ArrayMap public! :)Dianne Hackborn2013-07-161-23/+36
| | | | | | | | | | Also do some tweaking of the various container classes to synchronize them with the support lib and make it easier to copy code between the two. And update activity/fragment to use ArrayMap. Change-Id: I3cfe82392a17119dfc72c3d9961f64e1914f42be
* Update SparseArray docs to be more informative.Dianne Hackborn2013-07-121-2/+19
| | | | Change-Id: I5d8d17d46a69ccdcf6b29f93be3d44addd80ab61
* New ArrayMap class.Dianne Hackborn2013-05-241-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | This is a new kind of key/value mapping that stores its data as an array, so it doesn't need to create an extra Entry object for every mapping placed in to it. It is also optimized to reduce memory overhead in other ways, by keeping the base object small, being fairly aggressive about keeping the array data structures small, etc. There are some unit and performance tests dropped in to some random places; they will need to be put somewhere else once I decided what we are going to do with this for the next release (for example if we make it public the unit tests should go in to CTS). Switch IntentResolver to using ArrayMap instead of HashMap. Also get rid of a bunch of duplicate implementations of binarySearch, and add an optimization to the various sparse arrays where you can supply an explicit 0 capacity to prevent it from doing an initial array allocation; use this new optimization in a few places where it makes sense. Change-Id: I01ef2764680f8ae49938e2a2ed40dc01606a056b
* Clean up and expose LongSparseArray.Dianne Hackborn2012-02-101-51/+42
| | | | Change-Id: I15ba98d65e790ba45391cc7714f60b6e7de6ebfc
* ListView#getCheckItemIds() deprecated for ListView#getCheckedItemIds().Adam Powell2010-03-051-0/+22
| | | | ListView#getCheckedItemIds() now works more reliably.
* Fixes #1922373. Resolves a case of keys collision in Resources' cache.Romain Guy2009-06-181-0/+342
The Resources class keeps a cache of known resources. The keys used by the cache are stored as int primitives. For any given drawable resource, a key is built thusly: TypeValue.assetCookie << 24 | TypedValue.data In the case of a plain color drawable, assetCookie always equals -1, that is 0xFF once right-shifted and the data contains the color value. Which means the key for the following two colors is the same: 0xFF000000 0x00000000 Because of the int storage and the use of the (constant in this case) asset cookie, the alpha channel of a color is ignored. That means that if you first load an opaque black color (0xFF000000), subsequent loads of a totally transparent black color (0x00000000) will give you an opaque black color. A workaround is to use a transparent color that is not black, 0x00000001 for instance. Note that this issue would arise with any color and any opacity level. The solution to fix this issue is simply to change the cache to use longs instead of ints to represent the keys. A key thus becomes: TypedValue.assetCookie << 32 | TypedValue.data This allows us correct storage of all colors at the cost of a few bytes. The tradeoff is that we can keep caching ColorDrawable, which is definitely worth it.
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 15:55:05 +0000