Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: ((added tests for speech reco))
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Avoid most floating content by centering the requested content within
the view instead of just scrolling so that it's visible.
See ag/14213766 for the corresponding RecyclerView change.
Bug: 189487659
Test: atest ScrollViewCaptureHelperTest, plus manual testing.
Change-Id: I194288cf9e568614ffd7c45b7d046a5b982829d6
This changes the screen off animation so that the controller directly animates the LightRevealScrim and the shade keyguard UI, rather then tying these to the dozeAmount. This makes it easier for us to manage/cancel these animations, such as during the camera launch gesture, since the various doze components update their state asynchronously.
This approach also means that instead of actually changing everything to KEYGUARD as soon as the power button is pressed, we actually just show the LightRevealScrim and the shade's AOD UI. This results in far less jank. We then actually show the keyguard once the animation finishes or is cancelled.
Bug: 169693662
Bug: 169739682
Bug: 181020504
Fixes: 185567665
Fixes: 189342687
Fixes: 185567665
Fixes: 183195436
Test: atest SystemUITests
Test: trigger screen off and cancel it
Test: trigger screen off and don't cancel it, make sure it wakes up fine
Test: disable 'power button locks instantly' and make sure it doesn't lock the device, both when the animation finishes or when it's cancelled
Test: press the power button twice in rapid succession
Test: press the power button twice in slower succession about 200ms apart (which triggers the camera onWakingUp vs onFinishedGoingToSleep)
Test: press the power button 5 times, make sure emergency gesture comes up
Test: disable AOD, observe no screen off animation and lock functionality works
Change-Id: I1c44304becdadfd37bab7fd81286a9702e5d6141
used to collect binder latency data from bluetooth and telephony.
This is a direct cherry pick from internal with no changes: https://googleplex-android-review.git.corp.google.com/c/platform/frameworks/base/+/14236409
Test: latency collection is unit tested, this is just an alternative settings configuration
Bug: 180584913
Change-Id: Ide51afb7eb26a96c7692bceb0a22585a74f08aa7
Merged-In: Ide51afb7eb26a96c7692bceb0a22585a74f08aa7
* Instead of resolving colors as-needed, resolve the entire palette potentially used by the notification at the start.
* Centralize color logic and palette storage into Notification.Colors for easier unit testing.
* Adds unit tests for the Notification.Colors, including validating color contrast ratios for various colors.
* Fix a bug with ColorContrastUtil where the luminosity for dark/light font cutoff was 0.5, which resulted in a max contrast ratio of 1.9 for some colors. Now contrast ratios of 4.5:1 can be achieved for all colors.
* Removes a few of the color accessors in Notification.Builder which were infrequently used, and replaces them with direct use of Notification.Colors.
* Notification specific colors (primary, secondary, default) have only been used by colorized notifications for a few months. Remove the dark mode overrides of these, ensuring that colorized notifications have the same exact appearance in light and dark themes.
* Replace the use of the "default" color with the "secondary text color"; this practically only affects the alerted bell icon, is more consistent, and reduces complexity.
Fixes: 187881776
Test: manual
Test: atest android.app.NotificationTest
Change-Id: Ib8840d04093094c324d8bdce5b2e84c93a94db8d