Two benefits:
1) marshaling one flattened ApplicationInfo as part of a PackageInfo parcel
rather than one per included ComponentInfo; and
2) producing one ApplicationInfo at unmarshaling time and sharing the
reference to it among all included ComponentInfo instances, rather
than the previous implementation that generated a separate
ApplicationInfo instance for each ComponentInfo.
In some cases there can be many hundreds of ComponentInfo objects embedded
in a single PackageInfo, so coalescing duplicates is a significant win
for both payload size and object pressure.
Bug 19519502
Bug 20453802
Change-Id: Ib888810dad4471084fab9ead1ebb5e0b932905f1
- Added aapt command line flag --app-as-shared-lib to build app resources
that could be loaded as shared lib at runtime.
- Added new method AssetManager.addAssetPathAsSharedLibrary() to load an
app resource as shared library.
Bug 22487604
Change-Id: Ib9b33c35f9c2b7129f3ba205de03d4564623ea39
b46fdd4 introduced the concept of locale list to Configuration objects.
However, the change alway returned a locale difference when the delta
object locale list is set to the defualt (empty). We now don't return
a difference if the delta object as an empty locale list which is
consistent with what we did before the change and in line with how we
diff other configuration fields.
Bug: 23744091
Change-Id: I8c2c39d9a7e91e6a3a283312b745c4fdf6874396
default seinfo values are those for which policy lacks a
matching stanza in the corresponding mac_permissions.xml
file. Prior to this change the null object reference was
used to represent the non-matching state. This is in
contrast to a policy supplied default stanza which will
assign a non null seinfo value. Confused yet?
Basically, two default states were distinguished in the
code to describe the two cases where either a policy stanza
spelled out the base case seinfo label or not. Policy
writers could either supply a default stanza or rely on
the class instantiated value assigned by the ApplicationInfo
object. The hope was that the later assignment could be
used to help distinguish the cases where policy writers
intentionally white listed apps. This change will just use
the hard coded "default" string implicitly to describe all
cases and removes the idea of a policy supplied default stanza.
Change-Id: Ib7b01ee004775f24db9a69340a31784b967ce030
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
We also deprecate the locale attribute, but works around the cases in
which people would call it.
Also add various methods to LocaleList to support the features
Configuration requires.
Change-Id: Iacc537e5fc1a3d4c1ea7e5517347876ca4e07e0a
In the non split system user, only USER_OWNER is allowed to have restricted
profiles. This is now changed in split user mode, where multiple secondary
users can have restricted profiles.
Added UserInfo.restrictedProfileGroupId field, which defines parent/child
relationship between secondary users and linked restricted profiles. Adjusted
shared accounts handling logic to not assume that USER_OWNER is the only owner.
Bug: 23191995
Change-Id: I5f3fc2aa4f229103d6e75ec2c3dfce866b8007de
For the system user, enable apps based on the following conditions:
- app has no launcher icons or has INTERACT_ACROSS_USER_FULL permission
- app is whitelisted
- app is not in the blacklist
Bug: 23283899
Change-Id: I90fa266e8cfb28d002e5f792998fdddb6a1e6969
In the split mode, broadcast receivers and activities marked as
systemUserOnly will be running as system. This is a non-functional change for
non-split system user mode.
Bug: 22958572
Change-Id: I0f7d4f4a81275bc326bf630a776c695e8b5291a6
The activity can be positioned in the center or in one of the corners.
From there it shifts its position and tries to find a spot where it
doesn't collide with other activities.
The CL also includes a few fixes necessary to pipe the information about
the initial layout through the system.
Change-Id: I2aaf5b6d20044aafec713b7bd4193b05cfbd16f3
In the split system user model:
The only users that are not allowed to have managed profiles are:
- purely system user (user 0)
- guest users
- restricted profiles
- managed profiles
In the non-split system user model, the behavior does not change:
only the primary user can have managed profiles.
BUG:22956426
Change-Id: If908c30f110fd3e740770174f050c9b6cf87ce1b
...from Camera360 to Hangouts }
In the short URI toString, include a small summary of the ClipData (instead
of just saying it has a clip data). This makes it a lot easier to understand
what is happening when you look at the log of activity starts.
Also separate out the activity manager dump of URI permission grants from
its dump of providers, so it is easy to just look at that state.
Change-Id: I68093d9f279944e1aa9a29347075f237f4f55ed3
..in link-opening behavior. If a candidate is marked as "ask
every time," then the user is guaranteed to get a disambiguation
prompt including that candidate even when some other candidate
app is in the "always prefer this over a browser" state.
Bug 23147746
Change-Id: I904d8697a992b3f16f32b1c1b49c2bf9424c7137
Also makes native theme accesses thread-safe to avoid a race condition
when modifying the theme off the UI thread. Since drawable loading can
occur off the UI thread, we need to ensure Theme access is thread-safe
anyway.
This reverts commit c12ec70def.
Change-Id: If8fecde76d62738a8e55eddf898eafc468afdba2
Currently if the configuration width/height/smallest width changes, we
relaunch the activity or invoke onConfigurationChanged callback. When it
comes to size based configuration changes it might not be necessary: if
the size change doesn't pass one of the threshold defined by the
resources, it means there is no need to relaunch the activity.
In this CL the ActivityManager will receive the thresholds from the
application and use them to decide, whether to relaunch the activity.
The application reads the thresholds from the resources, specifically
from resource qualifiers used by the app.
Change-Id: Ie3cf0a172dc1ba0b865cf30c2962e7cfd9ad8436
