1. Move Extender outside of Builder
2. Rename apply/applyTo to extend
3. Move Wearable extenders into Notification.java
4. Collapse Builder model into single classes
5. Use Bundle for storage: no new parcelable types.
Minor fix to RemoteInput to use flags int for boolean options.
Change-Id: I40012fd0458ec103eabf75ed4c91f636e02f4c8f
RemoteInputs annotate actions and content intents to request
input from the user as part of an intent being sent. Results
are sent along using ClipData to avoid unparcel of developer
provided bundle values. A helper method is expexted to be used
to extract results.
Grouping allows notifications to be bundled together, with an optional
summary notification for display on older platforms. SortKey is an
important part of grouping since child notifications will likely have
a prescribed ordering. It is also useful in top level notifications
for apps that want to provide an ordering all other fields being equal.
Also provide a fluid way to to extend Actions and Notifications
using Extenders, e.g.:
Notification n = new NotificationCompat.Builder(context)
.setOption1()
.apply(new SomeExtender()
.setOption2())
.build();
This helps extension libraries provide a nice API experience for devs.
Change-Id: Ib3438ef854772c2c34d21bf1eb4ed7c9e032106f
Add a flag for PackageManager.hasSystemFeature to determine
if a functional webview is available on the device.
Bug: 13438487
Change-Id: I770f7e924b3e5fa6be0397904acf18c9306096e4
This feature will be listed by Android devices that allow for an
external camera to be connected to it. Such camera devices may
not always be available or connected.
Also clarify that android.hardware.camera.any also encompasses
devices that list android.hardware.camera.external.
Change-Id: I57497758877e4286c1f0116961731d483b56808f
Move the window swipe to dismiss plumbing off of Window.Callback into
its own internal interface implemented by Activity and Dialog. Make it
internal API instead of public. Apps should control this via the
window feature setting.
Change-Id: I64cd237fa7eab08719b2c34e31dac7d34f02563a
Make global action key timeout configurable: deprecated the old public method
and created a new one: getDeviceGlobalActionKeyTimeout.
Bug: 14441321
Change-Id: Ifa9b136984a9f02cfe4040baeff11275174967c5
Previously, the surface that backs a virtual display had to be set
at the time when the display was created. This change now makes
it possible to set or remove the surface later. The virtual display
is treated as if it were "off" while no surface is attached to it.
Change-Id: Ib4fdbbb8b4ee79f0fb9ceb648f9bda4a8fa6a2ca
isRound allows a view to determine whether the window it is contained
within obscures the corners of the window content. This allows views
aware of this property to adapt their layout accordingly.
Switch ViewRootImpl to use dispatchApplyInsets instead of
fitSystemWindows.
Change-Id: Ic3e3936b73815b2593cb9720af1a309fbd18406e
Conflicts:
core/java/android/view/ViewRootImpl.java
The constant does not have a final value yet but is useful for
documentation purposes during development.
Change-Id: Iddd9b956eff822a9a25e9df483b5bd3979189023
Applying insets is now handled by:
* WindowInsets class - Encapsulate system insets and local decor
insets into a single object, written specifically so that new inset
categories may be added later. Apps cannot construct their own
WindowInsets, only clone with optional modifications. This is to
prevent losing data in the event of new insets added in the future.
* onApplyWindowInsets - Actually perform the application of insets.
* OnApplyWindowInsetsListener - Allow an app to use a separate
Listener object to apply insets to a View. This allows for things
like support lib integration in custom views written for older
versions where the verifier would otherwise complain about the use
of the new WindowInsets class as a method parameter. It also allows
for applying insets in a custom way without writing a custom view.
* dispatchApplyWindowInsets - Dispatch the call to self and children
in turn, if applicable. An OnApplyWindowInsetsListener will override
the behavior of the view's default onApplyWindowInsets method; a
listener wishing to call down to the 'superclass' implementation as
part of its own operation should call view.onApplyWindowInsets. App
code should generally not override this method and instead override
onApplyWindowInsets or provide a listener.
Compatibility support with the existing fitSystemWindows method has
been provided in both directions: for code that previously called
fitSystemWindows on arbitrary views and also for code that overrode
the fitSystemWindows method in custom views. A view that supports the
newer onApplyWindowInsets mechanism should not mix that behavior with
other calls to fitSystemWindows or vice versa. Support lib-style code
should take care to consistently use one mechanism or the other at
runtime.
Change-Id: Ie88b96e0382beb5d3c3f6cd013f7043acbc0a105