...broadcasted repeatedly at every boot time
Remember the last done pre-boot receivers, so that if we have
a new pre boot receiver appearing (without the platform version
changing), when we re-write the file of done receivers it will
contain all of them, not just the new one.
Change-Id: I4ed3478edc549d4b023ec4b3719111bc4d970ae4
Permission denied when trying to launch an activity from a notification
We don't remove pending intents when updating an app, which is necessary
to keep app widgets and other things working. However, when uninstalling
an app, we should clear out all of its pending intents.
Change-Id: I95067b31098115b5a7b127766fd093750063bbb8
This may mean that secondary networks have bad network settings,
but currently default settings are overriden by secondary nets
which seems worse.
bug:13211589
Change-Id: I08d56e618208781bf6b21a88663c2b8503a4f226
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Cherry-pick from master.
Change-Id: I2d6081dd62f50f7d493045150b327ed120de7abd
The ACTION_EXTERNAL_APPLICATIONS_UNAVAILABLE broadcast now uses the
EXTRA_REPLACING intent extra when it is sent as part of an upgrade operation
on a forward-locked application. Update PackageMonitor to recognize this
new information and express it appropriately to the observer.
Bug 11988313
Cherry-pick from master.
Change-Id: Iecea1876ffc918f23f9fa5845f1f89ed8d740dd5
When switching USB modes there are often spurious connect and disconnect events
that occur before reenumeration is complete. There is currently a 1000ms timer
to "debounce" the disconnect events. But with some USB accessories, this timeout
is not long enough, which results in an endless cycle of attempts to enter
USB accessory mode when the phone is connected.
To fix this, we now wait up to 10 seconds for the host to successfully configure
the device when entering USB accessory mode before giving up.
This is separate from the existing debounce timer, so the behavior of the
USB state change broadcasts are not affected.
Bug: 12877769
Change-Id: I7aa61f8a618546d749a7ddfc97bf103029a73d03
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
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
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
