Introduced new 'extractNativeLibs' attribute to manifest/application.
Setting it to false prevents installer from extracting library from apk.
The default value for extractNativeLibs is true.
Bug: 8076853
(cherry picked from commit ff193d642e)
Change-Id: I1aa2c039bb2a590ae72f256acc9ba5401c2c59b1
In installPackageLI, dexopt is now performed on a staging directory of the app
(dexopt phase 1). For each codepath:
- /oat/<isa> directory is created
- dexopt output goes to the newly created directory. Optimized files have
.odex extension.
Bug: 19550105
Change-Id: Iec59790d97837b78af82b079fd1970de3388c91d
The attribute declares whether the app intends to use cleartext
network traffic (e.g., HTTP, WebSockets, XMPP, SMTP, IMAP -- without
TLS or STARTTLS). The default value is true. If set to false, the app
declares that it does not intend to use cleartext network traffic. In
this case the app requests the platform, tooling, and third-party
libraries to prevent it from using cleartext traffic. The danger of
cleartext network traffic is that its confidentiality, authenticity,
and integrity are not guaranteed.
This feature is designed to help apps which care about security of
data exchanged over the network. These apps can accidentally
regress/downgrade to using cleartext network communications. This
typically happens when the server the app communicates with all of a
sudden tells it to use cleartext communications (e.g, HTTP URL
instead of an HTTPS URL) or when one of the components of the app gets
updated and regresses to cleartext communications without the
developer noticing.
In general, the prevention measures are on best effort basis. It's
impossible to automatically prevent all instances of cleartext
traffic. For example, an app bent on bypassing restrictions could
perform low-level network I/O with unusual TCP packet fragmentation,
or could use a custom application-level protocol.
The expectation is that most apps use libraries for network
communications and these libraries over time will start to honor this
flag, thus increasing the protections offered by it.
Bug: 19215516
Change-Id: I8700d51ddbc5d528faa4b6a5fa5bc9551ad02d13
performDexOptLibsLI and related methods were extracted to PackageDexOptimizer
class. Minor refactoring of PackageManagerService.
This is a non-functional change. It should simplify further work to allow
storing OAT files inside package dir.
(cherry picked from commit eeea67b8c3)
Change-Id: I3494a2da70605362bb6fb4625ffbee1cbe1cd457
Using a static Pattern in UriMatcher prevents compile-time
initialization.
It is also not efficient, as String.split has a fast path for simple
splits.
Bug: 19542228
Change-Id: Ie9e5bfe6da04c6d05ec10b1426d0cd136ef46ef2
The public API field android.content.pm.ApplicationInfo.flags can
support only 32 flags. This limit has been reached. As a short term
workaround to enable new public flags to be added, this CL moves flags
which are not public API into a separate new field privateFlags and
renames the affected flags constants accordingly (e.g., FLAG_PRIVILEGED
is now PRIVATE_FLAG_PRIVILEGED).
The new privateFlags field is not public API and should not be used
for flags that are public API.
The flags that are moved out of ApplicationInfo.flags are:
* FLAG_HIDDEN,
* FLAG_CANT_SAVE_STATE,
* FLAG_FORWARD_LOCK, and
* FLAG_PRIVILEGED.
NOTE: This changes the format of packages.xml. Prior to this CL flags
were stored in the "flags" attribute. With this CL, the public flags
are stored in a new "publicFlags" attribute and private flags are
stored in a new "privateFlags" attribute. The old "flags" attribute
is interpreted by using the old values of hidden/private flags.
Change-Id: Ie23eb8ddd5129de3c6e008c5261b639e22182ee5
When updating the RegisteredServicesCache, don't remove any packages
that are not in the list of modified packages.
Bug: 19228972
Change-Id: Id4f264403b7ceca9005854dfbbc25abfd7b54889
Issue #18983662: API Reivew: clarify Intent docs for URI_ANDROID_APP_SCHEME
Issue #19019830: Bump up battery stats checkin version
Change-Id: I0bd8f32b9d8d5978bd01d421ea2232d20def340a
Symptom:
Assume a foreground broadcast FG and a background BG.
If a recevier registers both FG and BG. When sending
BG and FG to the receiver, and the receiver BG receiver
completes first, its finishReceiver will trigger next FG
receiver rather than BG, and also deliver wrong result
code/data to the next.
More detail and sample:
https://code.google.com/p/android/issues/detail?id=92917
Root cause:
Due to BroadcastQueue:getMatchingOrderedReceiver will match
by receiver(IBinder), so the caller ActivityManagerService:
broadcastRecordForReceiverLocked will always match the first
queue(fg) if a receiver is both receiving fg and bg.
Solution:
Add a parameter flags to finishReceiver, then server side
could know the finished receiver should belong to which queue.
Another general solution but with bigger scope:
I60dce4a48e20c1002a61a979e4d78b9b0a8b94a0
Change-Id: I913ca6f101ac8ec6c7a8e42754e6781f80247b7f
This prevents our lint tooling from complaining that we're passing
invalid values when trying to get the MediaProjectionManager.
Bug: 18830590
Change-Id: I34633248e895b0ac7f5083e18a7d2385ca6f8adb
...testCallActivityOnNewIntent test fails with LMP-MR1 Release.
Check for null.
Also fix some small issues with converting intents to/from intents.
Change-Id: Ic391cc57552635935af9a271b2d09353257f6d14
This reverts commit 6aee1d2ba5.
But leaves in some of the improved documentation.
Bug: 18281970
Bug: 18573576
Change-Id: I320f2229456ac039bc8f3cd8bc8b4ea6cf0e80eb
...is installed with <provider> with empty string.
Don't allow empty authorities, just like we don't allow null authorities.
Change-Id: I5c64592a639efe4dba848bd6f0efe4257f1565a2
This is a landmine for developers. If they need to obtain an unthemed
drawable, they should be using an explicit null theme.
BUG: 18579576
Change-Id: Ibca6b4c3e8e50dca144571244e035caec6fa91f8
Apps delivered as multiple split APKs must have identical package
names, version code, and signatures. However, developers may want
to iterate quickly on a subset of splits without having to increment
the version code, which would require delivery of the entire app.
This change introduces "revision codes" which can vary between
split APKs belonging to the same app. An install is valid as long
as the normal version code is identical across all splits. Splits
can be added/removed to an app over time, but if a split is present
across an upgrade the revision code must not decrease.
Since system apps could have been updated with splits, only revert
to the built-in APKs if the version code is strictly greater than the
data version. Also fix bug to enable inheriting from system apps
when adding splits.
Bug: 18481866
Change-Id: I34d8e14c141a8eb95c33ffe24b4e52d6af5c8260
