| 560830c9f06d07d97055426420709733571ca05b |
|
16-Jun-2017 |
Todd Kennedy <toddke@google.com> |
Track both framework and app overlays per package
Always bundle framework and app overlays. The old implementation, where
framework and app overlays were tracked independently, lead to an error
in the following scenario:
1. Enable app overlay -> change reflected in app
2. Enable framework overlay -> error: no change reflected in app
3. Disable app overlay -> change reflected in app, including framework
overlay
This change also leads to better architecture since the package manager
no longer needs to know that an app's overlays consist of both framework
and app specific overlays. Instead, that knowledge is handled by the
overlay manager.
Also, correct indentation in "cmd package dump packages" output and
remove obsolete constant DUMP_ENABLED_OVERLAYS.
Test: Manual
Change-Id: I707fc00052a15b22fb8c17e6155732520e6b2e52
Bug: 62680061
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| ada8deb43649aed879ceba28daee4af69ae0cc8d |
|
12-May-2017 |
Adam Lesinski <adamlesinski@google.com> |
OMS: Setup state for users on boot and when added
Some users never get switched to (managed profile/work profile) so the
overlay state for a user would never be setup (but they could still show
UI and apps).
This change ensures that user state is setup after an OTA to android O,
and whenever a user is added.
Bug: 37899201
Test: manual (add user via Device Admin sample: vendor/google/tools/DeviceAdminSample)
Change-Id: If214e26e39b18c2861794baf5c608a47d536e5ff
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| d11c5510b13171878f8d6f6a3424c7b2418c3031 |
|
11-Apr-2017 |
Adam Lesinski <adamlesinski@google.com> |
OMS: Fix bug where overlay settings wouldn't persist
The dead user check was using a List.removeAll() call to find
the subset of users that have been removed and need deleting
from the overlay settings. The target class, UserInfo, does not
implement equals(), therefore no UserInfos would be removed from
the set and all user IDs would be candidates for deleting.
This change avoids the UserInfo class entirely and manipulates userIds.
Bug: 36099320
Test: Pick a theme and reboot.
Test: Theme should still be applied on next boot.
Change-Id: I1ee57839515460bf578664dfe1bd67df7d10d041
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| c745f42169df6687a764e48b65878f22965c1530 |
|
06-Apr-2017 |
Adam Lesinski <adamlesinski@google.com> |
OverlayManagerService: Make broadcasts/updates explicit
Previously there was a listener attached to the Settings object
which would fire any time a single settings change was made.
This made it very inefficient to do batch updates.
This change makes the Settings object return its mutated status
on each call to a mutating method, allowing the caller to keep track
of whether or not to notify the listener of any changes.
This allows for the implementation of setEnabledExclusive, where
all but the target overlay are disabled and only a single notification
/ update is sent out.
Bug: 36099320
Test: manual (with OverlayManagerService.DEBUG = true), observe logcat
Test: when Going to Settings -> Display -> Advanced -> Themes and
Test: selecting a theme.
Change-Id: Ic8b8ca3ba0cf5d2d682bf6dac5a6c82e4f0f2502
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| 929ed8d2f46209026cfa6f4baa68b551d54401a0 |
|
07-Mar-2017 |
Jason Monk <jmonk@google.com> |
Add OverlayManagerService#setEnableExclusive
This lets settings use one call to set the current theme overlay
for the "android" package.
Test: Change theme in Settings -> Display
Change-Id: Ia566e58c5479dedb7184f4218151f8080f8ebc0f
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| 94ab1a66a51a9ee8588ac7af8025299c01bf5e6f |
|
06-Mar-2017 |
Fyodor Kupolov <fkupolov@google.com> |
Init of OverlayManagerService on a parallel thread
Expensive parts of initialization (like idmap) are now done on a separate
init thread.
The service waits for init to complete in PHASE_SYSTEM_SERVICES_READY,
before affected apps can start.
Boot time saving: ~300ms on marlin.
Test: rebooted and verified that OverlayManagerService init is completed
before any app process is started
Bug: 35949883
Change-Id: Ibdf0174c50cfa95fc8f1cb014ad0a03ff49f4d1f
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| a5ca62408381058c12bd5a1fe3b30f2512a73e03 |
|
02-Mar-2017 |
Adam Lesinski <adamlesinski@google.com> |
OMS: Introduce default overlays
Default overlays are applied at first boot. They are specified by
package name in system property ro.boot.vendor.overlay.theme as a
semicolon separated list.
Eg:
ro.boot.vendor.overlay=com.android.vendor.overlay;com.android.vendor.overlay_two
Test: manual (remove /data/system/overlays.xml and reboot)
Change-Id: I8a7443a9059ccabfe1a63b075b95f1b2b6db7dbd
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| 2e0d0f311100d8e0bb40d7d60b8498237f011f0c |
|
02-Jun-2016 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
OMS: integrate OverlayManagerService into framework
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Change-Id: Ib8afa05ccab4e2db558f89ce4423983c086bb61a
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| 95459806920dec34abb3214ab6e1a9b9213a2a61 |
|
23-Feb-2017 |
Guang Zhu <guangzhu@google.com> |
Revert "OMS: integrate OverlayManagerService into framework"
Bug: 31052947
Bug: 35697944
This reverts commit 21a3d1ad686dee97b9cf0ed80389ee2ab0d48013.
Change-Id: I2d86931020301524c26cf8c8e80d557c97fdd6c3
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| 21a3d1ad686dee97b9cf0ed80389ee2ab0d48013 |
|
02-Jun-2016 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
OMS: integrate OverlayManagerService into framework
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: Idc96dae6fc075d5373aa055bbf50e919136d7353
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|
| eabc9e95768e7ac9acc3b32dc9ac2edf99c9e2c5 |
|
15-Dec-2015 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
OMS: introduce the OverlayManagerService
Add a new system service to manage Runtime Resource Overlays. This will
offload the PackageManagerService and allow administration of overlay
packages while affected packages continue to execute.
Overlays can be enabled or disabled during runtime. Running applications
will re-create their ResourcesImpl objects and restart their activities
via the usual activity life cycle.
The order in which a set of overlays is loaded may also be changed
during runtime. The underlying mechanics are the same as for when an
overlay is enabled or disabled.
When an overlay changes state, e.g. becomes enabled, the
OverlayManagerService will broadcast one of the new intents
android.intent.action.OVERLAY_ADDED, *_CHANGED, *_REMOVED or
*.OVERLAYS_REORDERED.
Clients that wish to read information about overlays for users other
than themselves are required to hold the
android.permission.INTERACT_ACROSS_USERS_FULL permission. This mirrors
the protection level of PackageManager.getPackageInfo.
Clients that wish to change the information are required to
hold the permission android.permission.CHANGE_OVERLAY_PACKAGES.
Each pair of overlay package and corresponding target package is
respresented by a new OverlayInfo class. This class mirrors the
existing PackageInfo class.
Overlay packages are handled per Android user. The data is persisted in
/data/system/overlays.xml.
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: I15325e173193df3240b8dc0a58c852fd7a3d5916
/frameworks/base/services/core/java/com/android/server/om/OverlayManagerService.java
|