Activities can call NfcAdapter.invokeBeam() to
manually invoke the Beam animation. Any NFC tap
is then enough to complete the transaction.
Also, added NdefRecord convenience method for
creating Text records.
Bug: 5134061
Change-Id: Ia9df360d1d7e8451157c85a6d12f2a4eec924960
The AbsListView sub-scroller knows nothing about layout. That's now
handled by ListView and GridView, with subclasses of AbsListView using
the default PositionScroller. Removes unnecessary (unreleased) APIs.
Also fixes a bounds check that was using the item position rather than
the child view position.
BUG: 13006641
Change-Id: I2adb0f15623e32295facf81f5ada974083ba03ce
Adds a method to AbsListView for translating from position to row
and vice-versa. Doesn't NPE this time.
BUG: 3434554
Change-Id: I6a731aedda6d951ad46322dbe87df00b8d34a22c
ProfileOwners, like DeviceOwners, are Device Admins that have
additional priviledges. ProfileOwners however are scoped per
user.
Change-Id: I1e22c85878e0672121e6ebbe97fca38591f992b2
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
First pass at API for cross-Activity Scene transitions.
Remaining work:
Transition back
Automatically capture hero element info
Transfer of surface texture to synchronize between Activities
Possibly use scene names to indicate preferred transition
Change-Id: I59d07de1fae694a46b92b1c82525daa301ec1377
PendingIntents and IntentSenders can now be launched. Still does not
work once the host activity has been paused and resumed.
Window manager TaskStacks now exist independently of Displays and app
windows persist after Displays are removed below them. Attaching the
stack to a new Display does not yet restore the windows to it.
Fixes bug 12747909.
Change-Id: I509007ee23fda400b353f483cf6ecce08177763b
When an application wishes to do low-priority background work when the
device is otherwise idle (e.g. in a desk dock overnight), it declares
a service in its manifest that requires this permission:
android:permission="android.permission.BIND_IDLE_SERVICE
to launch, and which publishes this intent filter:
<intent-filter>
<action android:name="android.service.idle.IdleService" />
</intent-filter>
This string is declared in the API as IdleService.SERVICE_INTERFACE.
The service must be implemented by extending the new "IdleService"
class, which provides the API through which the system will communicate
with the app.
IdleService declares three methods, two of which are lifecycle callbacks
to the service, and the third of which is for the service itself to
invoke when appropriate. The lifecycle callbacks are
public abstract boolean onIdleStart();
public abstract void onIdleStop();
The first of these is a notification to the service that an idle
maintenance interval has begun. The service can then spin off
whatever non-UI work it wishes. When the interval is over, or if
the OS determines that idle services should be shut down immediately,
the onIdleStop() method will be invoked. The service must shut down
any background processing immediately when this method is called.
Both of these methods must return immediately. However, the OS
holds a wakelock on the application's behalf for the entire period
between the onIdleStart() and onIdleStop() callbacks. This means
that for system-arbitrated idle-time operation, the application does
not need to do any of its own wakelock management, and does not need
to hold any wakelock permissions.
The third method in IdleService is
public final void finishIdle();
Calling this method notifies the OS that the application has finished
whatever idle-time operation it needed to perform, and the OS is thus
free to release the wakelock and return to normal operation (or to
allow other apps to run their own idle services).
Currently the idle window granted to each idle service is ten minutes.
The OS is rather conservative about when these services are run; low
battery or any user activity will suppress them, and the OS will not
choose to run them particularly often.
Idle services are granted their execution windows in round-robin
fashion.
Bug 9680213
Change-Id: Idd6f35940c938c31b94aa4269a67870abf7125b6
