fe2462f3a60b34ee6b7d8764d92ae58fc0cd7dfd |
|
29-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Properly close fd backing a MemoryIntArray Use ParcelFileDescriptor only as an IPC transport to make sure MemoryIntArray manges its backing fd. Bug:30310689 Change-Id: Ib3cc13ef4ae2a744e5f7a96099570e0431847bce
/frameworks/base/core/jni/android_util_MemoryIntArray.cpp
|
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
/frameworks/base/core/jni/android_util_MemoryIntArray.cpp
|
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
/frameworks/base/core/jni/android_util_MemoryIntArray.cpp
|