commit 42aed1b8ecf591009f9e2df8eaca4f41074c37c8 changed the hidden
KeySet API to allow packages to retrieve keysets of other packages.
Change the PackageManagerTests to not expect a SecurityExeption
anymore and also make sure that this is supported.
Bug: 25935839
Change-Id: I18c00997a627c9df1eb3826650c1aa71f563a2bd
This patch updates the FloatingToolbar to look and transition
exactly as described in the UX spec.
It includes an animating (VectorDrawable) overflow button and
menu item buttons that sit in place during transitions.
Bug: 24257588
Change-Id: I2b3f84ba451800830878667ce1abd7a99b4f9fea
This reverts commit 8390b2ac85765e768d4b685077a96e6395d208b4.
The build break should now be fixed by
cbb1ba7f493116882b79578ec68646366f29cde4
Change-Id: I9bf21cc6dbdb5d515a665384dc6dfa464c3e6e2e
This adds the ability to promote private fields to public ones to
enable layoutlib to access them. This was first added in change
b556decf75b2b084e1aed54ac7fa23a141eedb7f, but reverted in
847b0d3ad22a47e0bca3d8bc8168fea7a0ba2f80. This is essentially a revert
of the change again, but without the SimpleMonthView related stuff.
Also, promote the Choreographer's field as is needed to support
animations.
Change-Id: Iee45a465c7a1cadd362c1841385941e6232e4900
For some markets we have to allow the user to review permissions
for legacy apps at runtime despite them not supporting the new
permission model. This is achieved by showing a review UI before
launching any app component. If an update is installed the user
should see a permission review UI for the newly requested
permissions.
To allow distinguishing which permissions need a review we set
a special flag in the permission flags that a review is required.
This flag is set if a runtime permission is granted to a legacy
app and the system does not launch any app components until this
flag is cleared. Since install permissions are shared across all
users the dangerous permissions for legacy apps in review mode
are represented as always granted runtime permissions since the
reivew requirement is on a per user basis.
Whether the build supports permission review for legacy apps is
determined by a build constant allowing us to compile away the
unnecessary code for markets that do not require a permissions
review.
If an app launches an activity in another app that has some
permissions needing review, we launch the permissions review
UI and pass it a pending intent to launch the activity after
the review is completed.
If an app sends a broadcast to another app that has some permissions
needing review, we do not deliver the broadcast and if the sending
app is in the foreground plus the broadcast is explicit (has a
component) we launch the review UI giving it a pending intent to
send the broadcast after the review is completed.
If an app starts a service in another app that has some permissions
needing review, we do not start the service and if the calling app
is in the foreground we launch the review UI and pass it a pending
intent to start the service after the review is completed.
If an app binds to a service in another app that has some permissions
needing review, we schedule the binding but do not spin the target
service's process and we launch the review UI and pass it a callback
to invoke after the review is completed which spins the service
process and completes the binding.
If an app requests a content provider in another app that has some
permissions needing review we do not return the provider and if
the calling app is in the foreground we show the review UI.
Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
- Use expanded view instead of HUN when possible
- Remember partial replies
- Back properly closes IME without closing shade
- Fix broken reorder animation
Bug: 22452379
Change-Id: Idb6ca8aed27cfb1f3d9b46f59e148b1b3b112fa7
Without this touch events on the input method will trigger focus change
if there is a window underneath the input. When focus changes, the input
method will go away too.
Bug: 25930832
Change-Id: I532cb9e78f6fe37b1ddfada75594fc695898a090
