Fixed a bug that cause Context.createPackageContext() to discard
display information. Likewise also fixes issues where the
activity token, override configuration, user handle, and
restriction state might be discarded.
As part of this change, reworked how Contexts are created to make
initialization easier to understand and less error-prone.
The init() methods have been removed and most of the state is
now stored in final variables.
Bug: 12015587
Change-Id: If795851f1cd078bef889b76a52e00d9b3c06ab11
* commit '9e413bf4e562d98b6efeb157369f152edd5f0261':
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
This is a change to add args to some of the profiler related
functions, including installd commands.
Also read properties and set command line options for the runtime
profiling parameters.
Changed calls to isDexOptNeeded() to isDexOptNeededInternal(). This
needs additional arguments passed for profiles.
Bug: 12877748
Change-Id: I1a426c9309d760bac0cf92daa298defee62287c1
Conflicts:
core/jni/AndroidRuntime.cpp
- Introduce a boolean extra for intent TIME_CHANGED that
specifies if the user wants a 24 hour format or not.
- Have the ActivityManagerService inform running processes
of changes to this preference.
- Add plumbing in ActivityThread to inform j.t.DateFormat
Change-Id: I05fafb903ae54e39c03a048b7a219dc5a93fd472
The calling package name will be used to check if an application is a
system application when deciding if a route should be exempt from VPN
routing rules.
Bug: 12937545
Change-Id: I2c09c875fe9bb9685871a0a801ddcbb32fc17405
* changes:
open("/dev/rtc0") failure in AlarmManagerService.setTime() should be non-fatal
Move time setting code from SystemClock to AlarmManagerService
On devices using /dev/rtc instead of /dev/alarm, updating the
time-of-day clock and RTC are separate syscalls. Hence the clock and
RTC could be left in inconsistent states if two threads called
SystemClock.setCurrentTimeMillis() simultaneously.
By moving this code into AlarmManagerService, we can put a global lock
around AlarmManagerService.setTime() and prevent the race condition.
Note that access to SystemClock.setCurrentTimeMillis() is now gated by
android.permission.SET_TIME, where before it was gated by filesystem
permissions (i.e., could the process write to /dev/alarm or /dev/rtc).
Change-Id: Ia34899a4cde983656305fd2ef466dfe908ed23c8
Signed-off-by: Greg Hackmann <ghackmann@google.com>
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
Null values were being written out as <null /> elements in the
XML prefs file (as expected). This allowed the getFoo() functions
to work correctly because they treated null values as missing mappings
but containsKey would fail.
bug: https://code.google.com/p/android/issues/detail?id=64563
Change-Id: I1f466d01db96bf26e208d4fed3a6f257228bea5d
For storing pointers, long is used, as
native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I7aee49dc26cf6c86af8f1d882e9cd1cc145a1977
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
We now update Dalvik's process state through VMRuntime when the
process state changes in ActivityThread. This is used to determine
when to do trimming and will be used to determine when to do
compaction in the near future.
Bug: 8981901
Change-Id: I5eea272ba4ec2d1ed789b058d6457cb3c1fcf777
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Now with 100% less build break.
Bug 11716868
Change-Id: I2af4e93788068cfac97c0a48d3568c561eefa23d
