When the ActivityView is part of the home activity special checks
must be made. Things like don't move the home stack to the back
when the ActivityView activity is resumed.
Fixes bug 13119389.
Change-Id: I3a6040c9824dfd4b8ee97d58d131b14a519b470a
* 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>
Modified ActivityView to inject touch events it receives back into
its activity container. The container then injects the event into
the input system along with the display id of the underlying virtual
display.
Enhanced the input system to support concurrent dispatch of touch
events on multiple displays which is required for this to work.
Change-Id: I9cf1870db3be6f99a52ed9a1e3ceafe42c940093
Child TextureView should be positioned at origin of ActivityView,
with matching width and height. Previously, a container's padding
would be applied twice for example.
Change-Id: Ie0be10614a45aede4207abf986721385d04d8c76
If the ActivityView is not ready when the startActivity method is
called we now save the Intent until the ActivityView is ready.
Fixes bug 12821638.
Change-Id: I30ebb2699963f174cc2d5a3fb77a99ed33a4252b
PendingIntents and IntentSenders can now be launched. Still does not
work once the host activity has been paused and resumed.
Window manager TaskStacks now exist independently of Displays and app
windows persist after Displays are removed below them. Attaching the
stack to a new Display does not yet restore the windows to it.
Fixes bug 12747909.
Change-Id: I509007ee23fda400b353f483cf6ecce08177763b
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
- Release Surface and VirtualDisplay when shutting down ActivityView.
- Shut down child stacks when relaunching parent activity.
Change-Id: I60314b2b43bd2da5406cf6ec871293b5baca157c
With an existing ActivityContainer a caller can now create an
ActivityView which consists of a new VirtualDisplay immediately
attached to the ActivityContainer.
Change-Id: Id70333dcbef55d524a87df8f8c92d72ca5579364
When BinderProxy is passed in as the IBinder for
getEnclosingActivityContainer the activity manager cannot turn it into
an ActivityRecord. This causes NPE in ActivityThread which is Not Good
(tm).
Allowing null to be returned when requesting an ActivityContainer and
handling it appropriately fixes this bug.
Fixes bug 12473669.
Change-Id: I6937636042f8853b3ddc2df40be010e7391e41a5
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>
- Abandon ActivityContainer.startActivity() in favor of
IActivityManager.startActivityAsUserInContainer().
- Modify Am to test starting an activity on a container.
- Create a DisplayContext as the base context if the activity token
is on a different display.
- Test for home display in more cases when manipulating home stack.
- Rename mDisplayInfos => mActivityDisplays.
- Create new method for moving task to front of stack regardless of
which display it is on.
Change-Id: I4fcb83ae844c5839ee3e2722229623d1a80ed921
- 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
StackBox is too constraining. Adding size and position to TaskStacks
directly makes stack positioning and management more flexible and
prepares for ActivityView.
Change-Id: I33c6b4e1c23a5a8069fd507c160bcb34e4d287b2
(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
