The dreams manager also manages dozing. It has a minimal footprint
so there is no real reason to disable the component (it just makes
debugging more difficult).
Improved the documentation of the config_dreamsSupported resource
to clarify exactly what it controls.
Bug: 12494706
Change-Id: I78244846f7c1ddfd11bc1605af59b0db91337971
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
Support any number of overlay packages. Support any target package.
UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes
<overlay targetPackage="com.target.package"/>
For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.
THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').
UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.
Zygote initialization
Initial AssetManager object created
+ idmap --scan creates idmaps for overlays targeting 'android', \
stores list of overlays in /data/resource-cache/overlays.list
AssetManager caches framework-res.apk
+ AssetManager caches overlay packages listed in overlays.list
Android boot
New AssetManager's ResTable acquired
AssetManager re-uses cached framework-res.apk
+ AssetManager re-uses cached 'android' overlays (if any)
App boot
ActivityThread prepares AssetManager to load app.apk
+ ActivityThread prepares AssetManager to load app overlays (if any)
New AssetManager's ResTable acquired as per Android boot
SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.
LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.
When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.
Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:
<overlay targetPackage="com.target.package" priority="1234"/>
Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.
Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.
The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.
+------+------+- -+------+------+
| 0x01 | | ... | | 0x7f |
+------+------+- -+------+------+
| |
"android" Target package A
|
Pre-installed overlay B (priority 1)
|
Pre-installed overlay C (priority 2)
Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e
Added new AndroidManifest permission:
android.permission.READ_PRECISE_PHONE_STATE
Added the following PhoneStateListeners and corresponding broadcast intents:
onPreciseCallStateChanged(PreciseCallState callState);
onPreciseDataConnectionStateChanged(PreciseDataConnectionState dataConnectionState);
broadcastPreciseCallStateChanged(int ringingCallState, int foregroundCallState, int backgroundCallState,
int disconnectCause, int preciseDisconnectCause)
broadcastPreciseDataConnectionStateChanged(int state, int networkType, String apnType, String apn,
String reason, LinkProperties linkProperties, String failCause)
Added TelephonyManager intent actions with their extras and constants:
public static final String ACTION_PRECISE_CALL_STATE_CHANGED = "android.intent.action.PRECISE_CALL_STATE";
public static final String ACTION_PRECISE_DATA_CONNECTION_STATE_CHANGED = "android.intent.action.PRECISE_DATA_CONNECTION_STATE_CHANGED";
public static final int PRECISE_CALL_STATE_*
Moved public static final int DISCONNECT_CAUSE_* from PreciseCallState.java to a new class DisconnectCause.java
Moved public static final int PRECISE_DISCONNECT_CAUSE_* from PreciseCallState.java to a new class PreciseDisconnectCause.java
Change-Id: If3b88c679507c529b746046c4a17cf6d9974bd09
Adding a micro theme affects 3 different GIT repositories:
1. Repository 'device/google/clockwork' - https://ar/398971
This has the overlay for the DeviceDefault for ClockWork
2. Repository 'platform/vendor/google_clockwork' - https://ar/399378
This has the changes to Clockwork Home to use the new micro Theme.
3. Repository 'frameworks/base' - https://ar/398959
This adds the *_micro.xml style/theme files.
Change-Id: Ib1e87953b052a9ec2ff0ea11dd0dfe55317442b4
As per 3GPP TS 31.101 Release 11 section 9.6, the number of digits
for UNBLOCK PIN (PUK) is always 8.
Change-Id: I4ea69fd8e2e8e96330d10a67b2d1f5a1859c1016
Add same named operator configuration for 404, 405, and 520.
That is, show roaming icon though same named operators.
Bug: 12121959
Change-Id: I9148bab727170f670fd2679db69b123b0526bb32
(Cherry pick from master)
As a next step they can be moved into separate directories to be
built as separate modules that may or may not be included in a
particular configuration.
Moves AppWidgetService, BackupManagerService, ClipboardService, DevicePolicyMS,
and WallpaperMS.
Change-Id: Idd92871c1828bdde81d85fe99a9c87a22d53169d
Extend wifi display connection timeout.
Show a notification while connecting to wifi display.
Ensure that remote display providers are really trusted before
connecting to them.
Bug: 11257292
Change-Id: Iad0caaa30d7946df818bc75ade071f2e377f8a53
Hide disabled routes from the chooser.
Fix layout of chooser dialog when the settings button is visible and
the list is very long to prevent truncation of the settings button.
Fix an issue when we fake the route connecting status when a route
is selected. The route changed notification needs to be propagated
to apps. Fake it better.
Immediately disconnect from a route when the connection is lost or
a connection attempt fails. Added a few new test displays for this
case.
Bug: 11257292
Change-Id: I360ab5dc937ad60d97592eab54b19f034519645e
