Apps delivered as multiple split APKs must have identical package
names, version code, and signatures. However, developers may want
to iterate quickly on a subset of splits without having to increment
the version code, which would require delivery of the entire app.
This change introduces "revision codes" which can vary between
split APKs belonging to the same app. An install is valid as long
as the normal version code is identical across all splits. Splits
can be added/removed to an app over time, but if a split is present
across an upgrade the revision code must not decrease.
Since system apps could have been updated with splits, only revert
to the built-in APKs if the version code is strictly greater than the
data version. Also fix bug to enable inheriting from system apps
when adding splits.
Bug: 18481866
Change-Id: I34d8e14c141a8eb95c33ffe24b4e52d6af5c8260
These are used when responding to getActiveNetworkInfo() (and cousins)
when an app is subject to the VPN.
Bug: 17460017
Change-Id: Ief7a840c760777a41d3358aa6b8e4cdd99c29f24
The animation scaled was not being factored in early enough in the
activity lifecycle. Also, setCurrentPlaytTime() was not accounting for
the scaled duration correctly. Finally, added setCurrentFraction() as
a more general-purpose seeking facility.
Issue #18222006 Animator duration scale ignored in some situations
Issue #17951668 add ability to seek fraction, not just time
Change-Id: Idad401f5ff5026d7046c36eee09d78a4793215dc
- hasCarrierPrivileges - renamed to getCarrierPrivilegeStatus
- setLine1NumberForDisplay should not be usable by apps that have MODIFY_PHONE_STATE
- setVoiceMailNumber should not be usable by apps that have MODIFY_PHONE_STATE
- setOperatorBrandOverride should not be usable by apps that have MODIFY_PHONE_STATE
Not addressed:
- setGlobalPreferredNetworkType() should not be usable by apps that have MODIFY_PHONE_STATE
The underlying call is needed by system apps (OMADM) too.
Bug: 18356155
Change-Id: Idc6468a0bd0b0c52b9de1d8446f98c90ac0b3238
This capability (a subset of FULL) indicates that a camera device
can capture high-rate (>= 20fps) bursts of images at full device
resolution, in at least the YUV_420_888 format.
It also guarantees that the synchronization latency for a device is
relatively small, so that fixed-setting bursts can be captured quickly.
Bug: 18281970
Change-Id: Ifc8fc43252a77097d804429d1c9f6fa71a95aa4f
There are many cases in real world applications where it is desirable
to continue processing messages on the Looper even when most other
messages have been suspended by a synchronization barrier pending
completion of the next drawing frame on vsync.
Internally the framework is able to mark certain messages as being
independent of these higher level synchronization invariants by
flagging them as asynchronous.
This change exposes the existing function and improves on the
documentation so that it is clearer what is meant by asynchronous.
Bug: 18283959
Change-Id: I775e4c95938123a364b21a9f2c39019bf37e1afd
