At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
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
It wasn't possible to start apps installed in /vendor/app
on a device where /vendor was a symbolic link to /system/vendor.
This is currently the default configuration for android (see
init.rc)
During installation a dex file is created at:
/data/dalvik-cache/vendor@app@blah.blah.apk@classes.dex
But dalvik would fail to start this app with the following error:
I/dalvikvm( 3453): Unable to open or create cache for /system/vendor/app/blah.apk \
(/data/dalvik-cache/system@vendor@app@blah.blah.apk@classes.dex)
Note that dalvik were trying to start /system/vendor/app while the
app was installed in /vendor. There was a conflict between the
package manager and dalvik on how to interpret paths. This change
makes the package manager consistent with dalvik.
Change-Id: I1c7e3c3ae45f97dd742cbf06f7965a7405c821a7
* commit '245b58d6f47740c09ebd47b75e6021c7cfb691af':
[ActivityManager]: Fix the activity visibility state not sync between ActivityManager and WindowManager
Changes in this patch include
[x] Long is used to store native pointers as they can
be 64-bit.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
[x] AssetAtlasManager is not completely 64-bit compatible
yet. Specifically mAtlasMap member has to be converted
to hold native pointer using long. Added a TODO to
AssetAtlasManager.java to indicate the change required.
Change-Id: I940433f601c6db998c1a8ffff338f5361200d5ed
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Symptom:
When press Home key to home screen, user is able to see the activity's window shown on top of wallpaper and below launcher(widgets).
Root Cause:
The ensureActivitiesVisibleLocked() is called pretty often (for example when a new process bound).
If the top activity "B" was finishing, then the previous activity "A" should be visible.
Therefore, the activity "A" window will be set to visible and then launched activity "A", but it does not updates the visible state in ActivityRecord for "A".
There has a timing issue that if a new activity "C" is started, "C" becomes the new top activity and be resumed.
In that case, Activity "A" window will remain visible even if it is behind a full screen activity "C" because the ActivityRecord.visble of "A" is still false, so the window visibility won't be update.
So when user press home key and back to launcher, the surface of activity "A" will be composed on top of wallpaper.
Solution:
Updates ActivityRecord.visible to true for "A". After "C" is started, the "A" will be called WindowManagerService.setAppVisibility() to set invisible, then called onStop() when execute ensureActivitiesVisibleLocked() again.
Change-Id: I536ba04b95d8d274fea6d679a6493e620bc981e2
Only one entry is allowed to be added to route table 60 for all
interface ipv6 link local addresses, so skip ipv6 link local
addresses on all interfaces when enabling NAT
Change-Id: Ibbe6c2bdae83586cdd38287089715f3433bbb91f
Signed-off-by: jiaguo <jiaguo@marvell.com>
setLightLocked() will update mColor. This will cause the led to not be
turned off after the pulse.
When notificationManager starts a attention pulse the led will be kept
on. Since attention is of highest prio nothing can turn it off.
This is fixed by resetting mColor back to 0 after the call.
Change-Id: Id60ef96e5c21b47c23002f0bcf2fae7fb3f2ca10
Since Kitkat, an app pre-loaded under /system/priv-app/ has
FLAG_PRIVILEGED. However, if the app updated and the device
rebooted, privileged flag is unset from pkgFlags. This patch
fix issue to assign privileged flag when scanning the updated
packages.
Bug: 12640283
Change-Id: Ic24b5882f65dabdfae9cc39da3d68661bed4fc31
It is not possible to send a broadcast before the system
boot is completed. If you do it anyway you will get an
IllegalStateException: Cannot broadcast before boot completed.
If a memory card is inserted or removed while the phone is
booting up, there is a risk that the MountService will try to
broadcast a storage intent too early, and cause the device
to crash.
Use FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT to avoid
problems with too early broadcasts.
Change-Id: Ied36a13d235df37c9788e45a35de40d919ae0cd0
Got a little too aggressive about cleaning up service state; need to
avoid removing services from an app until we are in the second loop
doing the final cleanup, otherwise we can leave services around with
restarting their process.
Also fix crash:
W/BinderNative( 667): Uncaught exception from death notification
W/BinderNative( 667): java.lang.ArrayIndexOutOfBoundsException: length=0; index=0
W/BinderNative( 667): at android.util.ArraySet.valueAt(ArraySet.java:301)
W/BinderNative( 667): at com.android.server.am.ActiveServices.killServicesLocked(ActiveServices.java:2069)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService.cleanUpApplicationRecordLocked(ActivityManagerService.java:12412)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService.handleAppDiedLocked(ActivityManagerService.java:3596)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService.appDiedLocked(ActivityManagerService.java:3744)
W/BinderNative( 667): at com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied(ActivityManagerService.java:1024)
W/BinderNative( 667): at android.os.BinderProxy.sendDeathNotice(Binder.java:493)
W/BinderNative( 667): at dalvik.system.NativeStart.run(Native Method)
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
The UsbDeviceManager is using a Scanner to identify
the ALSA card/device numbers to use for USB Gadget
audio, with a FileInputStream as its input.
Since FileInputStream implements the Closeable interface
it provides a close() method that should be explictly
called in order to close the stream source and release
any system resources that it might hold.
Change-Id: Ia0ff86d1f3cdf8916becec9c8603915dcbf4d2c8
Issue detail:
Assume X, Y are non-fullscreen activities.
a.Home starts an activity X in task A in application stack.
b.X starts an activity Y in <task A> or <new task B>
c.Activity X will be invisible.
How to fix:
Because the function "isActivityOverHome" means an activity is able to see home.
But there may have many non-fullscreen activities between the top non-fullscreen activity and home.
If flag "behindFullscreen" is set, those middle activities will be invisible.
So it should only take care from who is adjacent to home.
Then check two flags frontOfTask(task root) and mOnTopOfHome for constraining the condition.
Change-Id: I60bcea304976414e44835a0a38675aae365e9e19
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: Ib4435f0794740d545c1e640087849215e6844802
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Code that expected a single top level element in an XML file
was doing something like :
while (type != START_TAG) { next(); }
This would loop forever when the XML being parsed was empty,
where each call to XmlPullParser.next() would return END_DOCUMENT.
bug: https://code.google.com/p/android/issues/detail?id=64173
Change-Id: I7543203e976a8999ae471a6c2d629249a87011bb
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
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
If there is input to be handled during finish activity we can get a
keydispatching timeout ANR. The reason is that finish activity is some
times not possible, and the activity is instead put on a finish queue.
The activity will then be finished sometime in the future. When we add
the activity to the finish queue, key dispatching is paused, and there
is an ANR timer waiting for it to be resumed again. Since it can take a
long time before the activity is actually finished, we need to resume
the key dispatching to avoid the ANR.
Change-Id: Icea4ab3b5ad05c8bfbadf8f5cece1a59ec621469
1. When a print services is removed it is removed from the
installed and enabled services but not from the active
ones while it should.
2. If a package has more than one print service (very rare
but possible) we are executing the "make everything right"
code for each of them which is not very optimal.
Change-Id: I7f6fc4eef10b6757d3b2ede33eb298c3399c3ff7
- 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
