Also add new API for determining whether the current data network
is active, and thus better scheduling network operations. This
API is designed to not be tied to a mobile network -- regardless
of the network, apps can use it to determine whether they should
initiate activity or wait. On non-mobile networks, it simply always
reports as the network being active.
This changed involved reworking how the idle timers are done so
that we only register an idle timer with the current default
network. This way, we can know whether we currently expect to
get callbacks about the network being active, or should just always
report that it is active. (Ultimately we need to be getting this
radio active data from the radio itself.)
Change-Id: Iaf6cc91a960d7542a70b72f87a7db26d12c4ea8e
When a doze component has been specified in a config.xml resource
overlay, the power manager will try to start a preconfigured dream
whenever it would have otherwise gone to sleep and turned the
screen off. The dream should render whatever it intends to show
then call startDozing() to tell the power manager to put the display
into a low power "doze" state and allow the application processor
to be suspended. The dream may wake up periodically using the
alarm manager or other features to update the contents of the display.
Added several new config.xml resources related to dreams and dozing.
In particular for dozing there are two new resources that pertain to
decoupling auto-suspend mode and interactive mode from the display
state. This is a requirement to enable the application processor
and other components to be suspended while dozing. Most devices
do not support these features today.
Consolidated the power manager's NAPPING and DREAMING states into one
to simplify the logic. The NAPPING state was mostly superfluous
and simply indicated that the power manager should attempt to start
a new dream. This state is now tracked in the mSandmanSummoned field.
Added a new DOZING state which is analoguous to DREAMING. The normal
state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP.
The PowerManager.goToSleep() method now enters the DOZING state instead
of immediately going to sleep.
While in the doze state, the screen remains on. However, we actually
tell the rest of the system that the screen is off. This is somewhat
unfortunate but much of the system makes inappropriate assumptions
about what it means for the screen to be on or off. In particular,
screen on is usually taken to indicate an interactive state where
the user is present but that's not at all true for dozing (and is
only sometimes true while dreaming). We will probably need to add
some more precise externally visible states at some point.
The DozeHardware interface encapsulates a generic microcontroller
interface to allow a doze dream for off-loading rendering or other
functions while dozing. If the device possesses an MCU HAL for dozing
then it is exposed to the DreamService here.
Removed a number of catch blocks in DreamService that caught Throwable
and attempted to cause the dream to finish itself. We actually just
want to let the process crash. Cleanup will happen automatically if
needed. Catching these exceptions results in mysterious undefined
behavior and broken dreams.
Bug: 12494706
Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
This is far from complete but puts the basic components in place
for an app to interact with media sessions.
Change-Id: Icfe313f90ad76ae56badbe42b0e43fc5f68db36f
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
1. There are a few parcelable classes related to printing and accessibility
which are public but not added in the framework.aidl list so third parties
cannot write aidl interfaces that pass these classes. As these classes
are public it is resonable for devepers to be able to pass them between
processes.
Change-Id: I85da1de5198902b74f19d23e3fe16b45b4a11051
- Introduce concept of ActivityStacks residing on Displays and able
to be decoupled and moved around.
- Add a new interface, IActivityContainer for clients to handle
ActivityStacks.
- Abandon ordering of stacks based on mStackState and instead use
ActivityDisplayInfo.stacks<ActivityStack> ordering.
Progress towards closing bug 12078972.
Change-Id: I7785b61c26dc17f432a4803eebee07c7415fcc1f
* commit '3ee2c60e453e19b02b0ab52793045d2dd9a20912':
Pass a new samplesdir param to doclava as the starting point for generating samples browsing files. Removes older project-based configuration.
* commit '1448d3cd81a685c68b0102e8303c0db4e6e5668f':
Pass a new samplesdir param to doclava as the starting point for generating samples browsing files. Removes older project-based configuration.
* commit '3d763e258b6643d29a495b5dfb1cb376e6b61f87':
Doc change: move localized files into an intl dir. Build output remains the same for online, offline, and ds docs.
* commit 'acca12faea5fc1c9de63fdc08ae4d6bc0bad864a':
Doc change: move localized files into an intl dir. Build output remains the same for online, offline, and ds docs.
These are APIs for the new ThirdPartyPhone feature.
Note, these APIs can't actually be used yet on master for two reasons:
- initiating a call from a 3rd party app isn't possible yet because
the TelephonyManager APIs aren't being added to master.
- the TeleService implementation of these APIs aren't being added to
master.
Also, these APIs will be removed and the final ones will be added
once they're ready to be merged into master.
Change-Id: Ie783290451da448a011f813983e55b12047b5d99
This change adds a new media router service whose purpose is to track
global state information associated with media routes. This service
publishes routes to the media router instance in application processes
and handles requested state changes such as selecting or unselecting
global routes. The service also binds to remote display provider
services which can offer new remote display routes to the system.
Includes a test application for manually verifying certain aspects
of the operation of the media router service.
The remote display provider interface is essentially a stripped down
media route provider interface as defined in the support library
media router implementation. For now, it is designed to be used only
by first parties to publish remote display routes to the system so
it is not exposed as public API in the SDK. In the future, the remote
display provider interface will most likely be deprecated and replaced
with a more featureful media route provider interface for third
party integration, similar to what is in the support library today.
Further patch sets integrate these new capabilities into the System UI
and Settings for connecting remote displays.
Bug: 11257292
Change-Id: I31109f23f17b474d17534d0f5f4503e388b081c2
This interface allows applications to register services that offer
remote displays to the system. The system will then provide UI
to allow user to connect to these displays and enable mirroring.
Bug: 11257292
Change-Id: I34da5b9dfdaf71267bd3450c505bc1b7368d1b40
