* commit '59f61cc23d47f7ad714cf99be32fd70a66dba84e':
doc: Updated branding guidelines per request from @deniseamling.
Noted that OnSharedPreferenceChangeListener does not store a strong reference to the listener.
Before:
* CameraMetadata.Key<T>
After:
* CameraCharacteristics.Key<T>
* CaptureResult.Key<T>
* CaptureRequest.Key<T>
CameraMetadata#get has been removed (each metadata subclass has
its own #get now) due to java generic limitations (in particular
a type bound <T1<T2> extends Key<T2>> is an illegal bound).
CameraMetadataNative gets a new #dumpToLog function to dump the native
metadata to logcat.
Bug: 15091017
Change-Id: Ic56c54c0d184e209e20de374dc8a6d79527c209f
Fresh new revisions of our Roboto family of fonts, including family
aliases for sans-serif-medium and sans-serif-black. Enjoy!
Change-Id: I2337ccbd1767a7769deea885e0900f1ca4329779
Bug: 15170360
* commit '6547afc42bd74bb25d6f5a129e10bd225e3e61e9':
The layertype was incorrectly restored with overlapping alpha animations.
Decreased shadows between notifications slightly.
This could lead to weird clipping bugs on the lockscreen. We now simply
set its type to back to NONE after the animation.
Bug: 15186220
Change-Id: I884b6830d748309105ed62471cb8b6dee71d51fe
If we rely on mNotificationList to be sorted, then we cannot allow
records to change without a corresponding call to sort. Currently
RankingFuture may modify records in a separate thread, while the sort
doesn't happen until later. This creates a window for race conditions.
Instead, RankingFuture should record operations to be performed on the
record that will replayed later, in a transaction along with a sort.
We can't simply overwrite the old record completely because another
future may be concurrently modifying a different aspect of the record.
Two futures that attempt to modify the same aspect will be serialized
and the second will overwrite eventually the first.
Change-Id: I9223cabdc60f72d8e37e6d8119bea1e0127185c0
(cherry picked from commit 77d3e0d0297caca5358879d36e8ba77710eb8e82)
If we rely on mNotificationList to be sorted, then we cannot allow
records to change without a corresponding call to sort. Currently
RankingFuture may modify records in a separate thread, while the sort
doesn't happen until later. This creates a window for race conditions.
Instead, RankingFuture should record operations to be performed on the
record that will replayed later, in a transaction along with a sort.
We can't simply overwrite the old record completely because another
future may be concurrently modifying a different aspect of the record.
Two futures that attempt to modify the same aspect will be serialized
and the second will overwrite eventually the first.
Change-Id: I9223cabdc60f72d8e37e6d8119bea1e0127185c0
Newly introduced appear and disappear animations when in the shade.
Also introduced individual child delays such that notifications
appear in a slightly more appealing quantum way.
Also fixed a racecondition, such that added notifications already
have their final visibility state when they are added to the scroller.
Bug: 14081264
Change-Id: I18f5c57c2206f8e05996253981f540e97521e102
