am: 2e63b8f
* commit '2e63b8fdd908f91d508f7fe95eb8599ee5d08b88':
Show cascading popup menus if screen is big enough.
Change-Id: Iddd564294d1f075819225ed60fe48ff71204d6b5
am: 306ceb8
* commit '306ceb84b4c8833eaa46093fbba7638378eee456':
Accommodate NaN in new context menu methods.
Change-Id: Iddd48717534ab7ce5ef93aab0016190a50c42e9b
am: 6ba6820
* commit '6ba68207a3474bed3333038cd59120ab924ca967':
Show cascading popup menus if screen is big enough.
Change-Id: I91bebc9226ab008ccd42256928641d671ac2d448
am: 1fab8d9
* commit '1fab8d995e74de2128b45d9cae294c8d5ccf2fc6':
Accommodate NaN in new context menu methods.
Change-Id: Ifaf625d13b5dc57cf69f10ef1af99aef4acfecb6
am: fb24d4f
* commit 'fb24d4f07793df29d999819d5394b6000d140c0a':
Fix onPrepareActionMode() not being called
Change-Id: I933be0d2b28dd9d2f1dce17e2b746dadf3b9e764
am: 9412176
* commit '94121762ff47728fd8080f45f04cafb55b92079d':
Fix onPrepareActionMode() not being called
Change-Id: Ic6f51f65f9d82b490ef26c89725b228f0568bdd9
am: 0010741
* commit '0010741818127e6c9449fc49490f0bad14a76240':
Ensure local settings caches are not stale
Change-Id: I26c4f1f72eda3b2ebfb3ca6e086a0381d357471c
am: f71d7fe
* commit 'f71d7feef22db9e0cab2f32edc7440aedb86fdfe':
Ensure local settings caches are not stale
Change-Id: I356b9ad0b6dc1e91bfad140de1b9fc79ab6efef3
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
am: 1f803c3
* commit '1f803c3c75cf089f704e1cbf2d81b56597f6c263':
LoadedApk: Don't set up JIT profile support inside the system_server.
Change-Id: I9a8587ea42d116bdf60845e9f41b88c275c9b751
am: 2d4a222
* commit '2d4a222de157c693b16ca2b35a264dd92ae6abee':
LoadedApk: Don't set up JIT profile support inside the system_server.
Change-Id: I52d0cb275f3d01a094aefed65e43a2882d00679c
We shouldn't profile *any* packages loaded by the system_server, not
just the system_servers own ("android") package.
bug: 28241500
Change-Id: I5f3f477b40c758030a5bdc8e97d17cab6e68e204
Happens because mActionMode was set at the end
of the call, which means that invalidate() doesn't
actually do anything.
BUG: 28392319
Change-Id: Ifdc97c03dc43bfbe74790f90764d1575bd9ca951
Changes the policy for selecting packages which will be pre-verified
during post-OTA boot animation.
For Nx to Ny, an app is pre-verified if used in the foreground in the
last 7 days, or if its APK was loaded by other apps.
For M to N (or early N builds without detailed stats), an app is
pre-verified if it has any recorded use in the last 7 days.
Bug: 27902702
Bug: 27350503
Change-Id: I2b38daf017ecd0e5aa5ed596ed9351cffa03dbcb
