Originally the api 'getCropAndSetWallpaperIntent' does not check
whether the parsed parameter is a NULL pointer, as leads to the
whole app crash if it call this api with a null parameter accidentally.
A null pointer check logic is added into its original parameter check
logic, so that this API will throw an IllegalArgumentException if it
is parsed with a null pointer
Change-Id: Ib7de40e571419d09e1a744edc969eb7162766b75
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
* 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
Port the new style UI back into the framework from the support library.
There are now two dialogs: a chooser and a controller. We use the
same dialogs for selecting routes within app and within quick settings.
Note that the new UI does not support any grouping features since they
are deprecated and unused.
Bug: 11257292
Change-Id: I64e936a18d25ab75f0c470cbc1e7085f67004863
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
When I cleaned up how we maintained the lifecycle of the tracker with a
service, I broke most tracking of the service restart state. (Since at
that point the service is no longer associated with a process, so I
must clean up the tracker state). This change introduces a new special
case for interacting with a service tracker to explicitly tell it when
a service is being restarted. It also fixes how we update the process
state when services are attached to it, so it goes in and out of the
restarting state correctly.
In addition:
- Maybe fix issue #11224000 (APR: Dependent processes not getting added
to LRU list). We were not clearing ServiceRecord.app when bringing
down a service, so if for some reason there were still connections to
it at that point (which could happen for example for non-create bindings),
then we would so it when updating the LRU state of that client process.
- dumpsys procstats's package argument can now be a package or process
name, and we will dump all relevent information we can find about that
name.
- Generally improved the quality of the dumpsys procstats output with its
various options.
- Fixed a bug in ActivityManager.dumpPackageState() where it would hang if
the service was dumping too much, added meminfo to the set of things
dumped, and tweaked command line options to include more data.
- Added some more cleaning code to ActiveServices.killServices() to make
sure we clean out any restarting ServiceRecord entries when a process is
being force stopped.
- Re-arranged ActiveServices.killServices() to do the main killing of the
service first, to avoid some wtf() calls that could happen when removing
connections.
Bug: 11223338
Bug: 11224000
Change-Id: I5db28561c2c78aa43561e52256ff92c02311c56f
Move the logic for managing dimming the navigation bar
elements on the lockscreen into BarTransitions.
Replace search light + camera assets with new
versions at full brightness, and apply 50% dimming
at runtime, including the IME dismiss button.
Remove unused StatusBarManager _NOP hints.
Improve choreography between camera button +
password security (w/ IME). Fix a few found bugs
in PagedView.
Improve password security unlock transition, manually
fade in back along with the rest of the icons.
Bug:11221659
Change-Id: Ifd1f8c9f400d90542f0ca858b9a4deacabbd518a
When a client of a UiAutomationConnection is set it remembers its UID
and allows subsequent operations only from this UID. The connection
If the connection was not used, i.e. its client is not set, and an
attempt to destroy it is made the connection enforces the caller UID
to be that of the owner but it does not have an owner yet. Now if the
destroy method is called on a connection that is never used (has no
client) we do not enforce caller UID.
bug:11465888
Change-Id: I739dfc45e772ea970b6ab384e4420184724333a3
