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
Add new RIL commands and generic code cleanups.
The only changes required for OMA DM support are the
addition of five new methods in ITelephony.aidl for
reading/writing NV items and performing NV config and
radio resets (requires MODIFY_PHONE_STATE), along with
the new RIL request IDs in RILConstants.java.
Bug: 12864208
Change-Id: I958d2571580d98a49936ef2e6822e5ac086acbe2
- Better batching of history items. Fixed problems where empty
entries would be created because state toggles got lost.
- The string pool is now a HistoryTag pool, containing both a string
and uid; now an entry only requires 16 bits in the history data.
- Acquiring the first wake lock also now includes a HistoryTag
identifying who did the aquisition.
- Cleaned up printing of signal strengths and cell radio types.
- There was code that tried to allow you to add new history entries
while iterating the history... but these should never happen
together, so turned that into a failure... and fixed an issue
where we could leave the battery stats in a state where it
thinks it is continually iterating.
Change-Id: I1afa57ee2d66b186932c502dbdd633cdd4aed353
Remove setFlags(), which doesn't seem to be used, and make the flag
declarations private. The flags can be set with hide(), show(), and
setOpaque().
Change-Id: I2bdff0881d9397b0c4455f6663c2a1e8084df719
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
