| cc5a731fd725a4687625c93cf8490b63ce99884f |
|
23-Mar-2017 |
Jason Monk <jmonk@google.com> |
Remove "Allow persistent changes to the vendor overlay theme"
This reverts commit 2dc804be11444565e3d1d151c2a693db3ade94c0.
It also removes the related calls from UiModeManager.
Fixes: 32721178
Test: make & flash
Change-Id: Id371bccec611155cc6910e46b3277c3d27fc1c79
/frameworks/base/libs/androidfw/include/androidfw/AssetManager.h
|
| 7de2f9c73fbe93bfb7dff3c046cf7a3137599f6c |
|
01-Mar-2017 |
Jaekyun Seok <jaekyun@google.com> |
Reinstate codes to enable RRO on system server
Test: building succeeded and tested with sailfish
Bug: 35742444
Change-Id: I99d0f1d097525d3eb46255d6cf823f6ae2a02385
/frameworks/base/libs/androidfw/include/androidfw/AssetManager.h
|
| 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/libs/androidfw/include/androidfw/AssetManager.h
|
| 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/libs/androidfw/include/androidfw/AssetManager.h
|
| 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/libs/androidfw/include/androidfw/AssetManager.h
|
| 2dc804be11444565e3d1d151c2a693db3ade94c0 |
|
07-Nov-2016 |
Jason Monk <jmonk@google.com> |
Allow persistent changes to the vendor overlay theme
This allows the overlay being used to be changed without a new build
but still will require a reboot to take effect. Should no longer be
needed once hierarchical resources are in place, and can be removed.
Also fix check in fd_utils to point at correct location.
Test: Manual
Bug: 32721178
Change-Id: I2a63aea0c87791c8eb845d735cb1182716c8174d
/frameworks/base/libs/androidfw/include/androidfw/AssetManager.h
|
| f6113af2d6f6eebee68d3ac510fe96d38a7a39e9 |
|
04-Nov-2016 |
John Reck <jreck@google.com> |
Re-unite sources with their headers
Move all the includes for androidfw under
a common base path for that library instead
of frameworks/base/includes.
Also fixes -Werror issues that resulted in
no longer being -isystem.
Test: builds
Change-Id: Ic4312eb61b197af114dded5691d5ae1ec82923f7
/frameworks/base/libs/androidfw/include/androidfw/AssetManager.h
|