04df738bcb6584dd82b731a67f4cf8d6925b061e |
11-May-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Make settings cahches generation mechanism robust. Settings is using a MemoryIntArray to communicate the settings table version enabling apps to have up-to-date local caches. However, ashmem allows an arbitrary process with a handle to the fd (even in read only mode) to unpin the memory which can then be garbage collected. Here we make this mechanism fault tolerant against bad apps unpinning the ashmem region. First, we no longer unpin the ashmem on the client side and if the ashmem region is purged and cannot be pinned we recreate it and hook up again with the local app caches. The change also adds a test that clients can only read while owner can read/write. bug:28764789 Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
ndroid.mk
ndroidManifest.xml
rc/android/util/IRemoteMemoryIntArray.aidl
rc/android/util/MemoryIntArrayTest.java
rc/android/util/RemoteIntArray.java
rc/android/util/RemoteMemoryIntArrayService.java
|
53a441ca8eda5a3e6209a952b1bbd32a39e19a1c |
20-Apr-2016 |
Svet Ganov <svetoslavganov@google.com> |
Ensure local settings caches are not stale We used the system proterties as a shared memory mechanism to propagate information to local settings caches when the content has changed and the cache should be cleared. The system properties are unfortunately updated asynchronously leading to cases where clients may read stale data. This change adds a simple int array data structure backed by shared memory which guarantees individual values are atomically read and updated without memory tear. Multi- index opearations are not synchronized between each other. The settings provider is using the new data structure to propagate the settings generation which drives when caches are purged. We have a single memory array keeping the generation for different settings tables per user. Since memory array is not a compact data structure and the user space exceeds the memory array size we use an in-memory map from keys to indices in the memory array where the generation id of a key is stored. A key is derived by the setting type in the 4 most significant bits and the user id in the 28 least significant bits. The mapping from a key to an index is cleared if the user is removed and the corresponding index in the memory arry is reset to make it available for other users. The size of the memory array is derived from the max user count that can be created at the same time. bug:18826179 Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
rc/android/util/MemoryIntArrayTest.java
|
3ae3557ea3a9ad8429de9db14de62a4214a07cdc |
06-Apr-2016 |
Makoto Onuki <omakoto@google.com> |
Make FastXmlSerializer more suitable to persist arbitrary strings - Encode '\u000' - '\u001F', so KXmlParser can read them properly. Otherwise KXmlParser will ignore CRs/LFs in attributes, and CRs in text. - Originally FastXmlSerializer would throw if a string contains dangling surrogate pairs. Now we REPLACE them with. Bug 27792649 Change-Id: I10c547dad2475b68f60e9e8208d9a3eae8e20063
rc/com/android/internal/util/FastXmlSerializerTest.java
|
634c1f9d0d43c7874ea433188b45fdf944d98a5a |
19-Feb-2016 |
Mitchell Wills <mwills@google.com> |
Modify WakeupMessage to only send the message if not canceled Change-Id: I9ca6d3726fe25c706b644bf61119837a7cbe6db1
ndroid.mk
rc/com/android/internal/util/WakeupMessageTest.java
|
f979012c9b5891254177dae965b2b64d70b8c283 |
20-Feb-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Add a unit test for MessageUtils. Also fix a couple of issues in the code: 1. Check that fields are static before attempting to read them. Currently, if a non-static field's name starts with one of the specified constant prefixes (by default, "CMD_" and "EVENT_") we'd get an NPE. 2. Only read final fields. Change-Id: I0e07c4c27a66180cbaf7f2b1c235daafc080863b
rc/com/android/internal/util/MessageUtilsTest.java
|
3ca1ccb419ec56a191d724ff75c6943200c8cebe |
19-Feb-2016 |
Mitchell Wills <mwills@google.com> |
Merge "Fix FastXmlSerializerTest" into mm-wireless-dev
|
acd97e2e0fdcc50f20bc4836188e781583b10f1e |
19-Feb-2016 |
Mitchell Wills <mwills@google.com> |
Merge "Remove AsyncChannelTest because it does not test anything" into mm-wireless-dev
|
86821c07c2aa2594973c6e09a4d13bb620ebc45f |
19-Feb-2016 |
Mitchell Wills <mwills@google.com> |
DO NOT MERGE Disable failing test case Bug: 27258801 Change-Id: I832505e0feca9f0abbf627d009d5982a4437bf83
rc/com/android/internal/util/StateMachineTest.java
|
733fc6b6f9af33bae047e8296b9fc9d341f4f202 |
19-Feb-2016 |
Mitchell Wills <mwills@google.com> |
Fix FastXmlSerializerTest Change-Id: Ie984abae588927e65bdeffa5a6f5c58bd6ba0bf1
rc/com/android/internal/util/FastXmlSerializerTest.java
|
c91e57c1aac16b20e9862acc5fb24fc7a02dd79f |
19-Feb-2016 |
Mitchell Wills <mwills@google.com> |
Remove AsyncChannelTest because it does not test anything Change-Id: I7d3fe580a8c32ef3bd10895b51a7fc436f79919f
rc/com/android/internal/util/AsyncChannelTest.java
|
35402eb8ae461a0a19b1d99ea824b05750ca1bd9 |
19-Feb-2016 |
Lorenzo Colitti <lorenzo@google.com> |
Move tests for com.android.internal.util out of coretests These are very simple tests with no dependencies, and moving them out of FrameworksCoreTests makes it possible to iterate much more quickly. "runtest frameworks-core" takes almost a minute just to push to the device, before any tests even start running. Bug: 25691379 Change-Id: I8d99316a5940e0171883b97c578f9a6882b699a0
ndroid.mk
ndroidManifest.xml
rc/com/android/internal/util/ArrayUtilsTest.java
rc/com/android/internal/util/AsyncChannelTest.java
rc/com/android/internal/util/BitwiseStreamsTest.java
rc/com/android/internal/util/CallbackRegistryTest.java
rc/com/android/internal/util/CharSequencesTest.java
rc/com/android/internal/util/FastXmlSerializerTest.java
rc/com/android/internal/util/FileRotatorTest.java
rc/com/android/internal/util/IndentingPrintWriterTest.java
rc/com/android/internal/util/PredicatesTest.java
rc/com/android/internal/util/ProcFileReaderTest.java
rc/com/android/internal/util/StateMachineTest.java
rc/com/android/internal/util/XmlUtilsTest.java
|