am: 596a4a1
* commit '596a4a1592a8f5e7b708d884145e280df9b638d0':
Fix a bug where restartLoader would result in a stuck loader
Change-Id: I635309e5b37dfca8befdadeb578a71ae1619ac00
am: 9a5f9c2
* commit '9a5f9c208752bdb8c14fd2f2ef88408442f49c84':
API Review: Add @IntDef and other annotations to Menu Item flags.
Change-Id: Ie571f6cb9dc496349aeb2b56e2648fb549e2d3ad
Framework edition
In some cases restartLoader calls that happen in quick succession
could cause the new loader to become stuck and never run. Treat loader
restarts for loaders that have not yet started the same as starting a
brand new loader.
Bug 27437287
https://code.google.com/p/android/issues/detail?id=56464
Change-Id: Ia4e276fc8e63d43b9c52c6155cea827b194d8b19
am: 7a61d60
* commit '7a61d6031b0ce9de00bfc77caa196396ad1781d5':
Fix crash with a11y set text with text filters.
Change-Id: I2123ccd020f720ed28b0d0922e8f1dfdaa8261bb
* changes:
Unhide getHdrCapabilities and HdrCapabilities.
Plumb HDR capabilities to Display
Revert "Revert "Hook up HDR capabilities from native SurfaceControl""
am: 7f209d3
* commit '7f209d37f17d4df09475137c38b84a3338c84023':
API tweaks to PixelCopy and make it public
Change-Id: I1aac8afacfd054fe10fc26a73552608c51dfa9f5
-- Remove default constructor from public API since getEmptyLocaleList exists
-- Merge the Locale and Locale[] constructors by providing a single Locale… varargs constructor
-- forLanguageTags, get, toLanguageTags, size, need docs
-- get(int location) should be get(int index)
Plus general docs improvements
Bug: 28296200
Change-Id: I8b4e67184f8c723daebcd251f04947d48bbb5478
A text filter may shorten the text, so we need to use the text
that's actually in the View, not the text we requested, to move
the selection.
Also removing the override of performAccessibilityActionInternal,
which should have been done as part of adding text actions initially.
Bug: 28253708
Change-Id: I184f49dcba0238f4ccc222597cefca258393b263
If a package targets a pre-release SDK [eg a letter version] it should not
be allowed to be upgraded by a release SDK [eg a number version]. If one
absolutely must upgrade to a release SDK, use the "--force-sdk" option
during install.
Bug: 28345311
Change-Id: Ic9fb209968e7c5da2c80c5ca4c0f44f5125f610a
am: a86d1e0
* commit 'a86d1e0b5938cee1d76aefcc1e8967c353ea922d':
Accommodate NaN in new context menu methods.
Change-Id: I40a1d6b55b7f9cb422d35c1f0881efccd36cc290
When reusing a ViewRoot and DecorView as we do with preserveWindows
there are two issues with SurfaceHolders. First, we update the
SurfaceHolder callbacks when we call ViewRootImpl.setView. In the
case of preserved window relaunch, the DecorView is reused and there is
no call to setView. We need the ActivityThread to notify the ViewRoot
that something has changed. Secondly, we were assuming the only time
a new surface would be created for the purposes of SurfaceHolder
notification was when we previously did not have a valid surface.
Instead we need to check if the native Surface object has changed each time we
get a result from relayout.
Bug: 28331264
Change-Id: If1b4aab9b2ba579fa040e2a3ab4471842476d82f
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