* commit '23ef1b5e0b84e3bb726454b97846f91f2efad212':
A background started service is removed from mStartingBackground when timeout. Fix is to make sure mStartingBackground is updated to remove one.
...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
Changes in this patch include
[x] Long(64-bit) is used to store native pointers in
AssetAtlasService and related classes 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)
Change-Id: Ib4c77c134e3ad5b21732e20cde9a54a0b16bdab1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
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
The event onShutDownComplete are sent only when all
volumes are shutdown. (Not one for every volume.)
Change-Id: I6af521ee8285ca581efac7d3c5f013dfbff3ee30
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
