History log of /frameworks/base/core/jni/android_util_MemoryIntArray.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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