| ac3e0e590a7b425af20e2ac70569ced789155dde |
|
24-Jun-2016 |
Adam Lesinski <adamlesinski@google.com> |
Update DisplayMetrics when resizing
Previously the DisplayMetrics passed to a new ResourcesImpl
object would be generated from the default DisplayAdjustments.
We now use the correct DisplayAdjustments for the ResourcesImpl
and make sure to update them for things like rotation changes.
Bug:29619314
Change-Id: If2ba0d7670a4554dcd3fde9766e2337f20a191fd
(cherry picked from commit 8e8d23214a71d8813ebd3676b192924c530cb913)
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 4ece3d6bb18a609afcd0e82f0340b7d36ba24eea |
|
17-Jun-2016 |
Adam Lesinski <adamlesinski@google.com> |
ContextImpl: Keep DisplayAdjustments and Display in sync
Make sure that when our Resources get updated, that DisplayAdjustment
and Display properly reflect the potentially new screen dimensions.
Bug:28388969
Change-Id: I340550ea094ece87abc8790dd46aaa60ab3cedd3
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 25f48886b2bc2f4edc65d80ff836561853b7ed50 |
|
14-Jun-2016 |
Adam Lesinski <adamlesinski@google.com> |
ResourcesManager: Allow managed addition of library asset paths
This allows WebView to add itself to the ResourcesManager and
remain their even after configuration changes and multi-window
changes.
Bug:29112218
Change-Id: I2cb131ae2c61fb58c48babafdd46c1882be96aa9
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| c82f28a91370a2b01d36e35ca149a3da58b38f60 |
|
09-Jun-2016 |
Adam Lesinski <adamlesinski@google.com> |
Throw proper exception in ResourcesManager
In M we would bubble up a NameNotFoundException when failing
to load an assetmanager from another application. We switched
to throwing an IllegalArgumentException, which isn't something
anyone should handle.
This change has ResourcesManager throw Resources.NotFoundException,
which callers like ApplicationPackageManager can catch and rethrow
with the appropriate checked exception. This adds more detail to
errors than we had in M.
Bug:28876344
Change-Id: I250aeef8a4ccfd90c6abef2243edc1c5337ebde9
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 98bf12f99989ba2550fac83ee48ecbb6f1582f07 |
|
26-May-2016 |
Jeff Sharkey <jsharkey@android.com> |
Release AssetManagers when ejecting storage.
When ejecting a storage device, the system process needs to rapidly
release any open FDs to prevent itself from being killed by vold.
This change examines all ResourceImpls cached inside the system
process and evicts any that reference the storage device being
ejected. (ResourcesManager will gladly recreate any evicted entries
when asked again in the future.)
Also replace broken use of WeakHashMap, since we want the values to
be weak references, not the keys.
Bug: 28867548
Change-Id: Ib9cfc66497149b6d3f8d49213e9779408a331d2a
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| b61e405397200f78b1c652143cba7c751df05a00 |
|
20-May-2016 |
Adam Lesinski <adamlesinski@google.com> |
Improve performance of LocaleList with Resources
We allow each individual Resources object to select the best
Locale for the given APK. This allows one update to the configuration
instead of multiple updates, once the locale is chosen.
The Java locale is selected from the app context's locale.
Bug:28625993
Bug:27325465
Change-Id: I99e1e53f522e560f3b80bbd1e1c605f552dbdff0
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 23cbe85610f780134cc77dd4a54732a22ed6e86e |
|
18-May-2016 |
Yohei Yukawa <yukawa@google.com> |
Move LocaleList to avoid layering violation.
Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 8ce4e12c73837bda319c56f8b9e36cf310caf85e |
|
03-May-2016 |
Adam Lesinski <adamlesinski@google.com> |
Fix issue where existing Activity Resources references would not update
When relaunching an Activity, the DecorView and ViewRootImpl is re-used,
along with the IBinder activity token. This means that when we create
new resources, we end up just updating the base Activity resources.
However, we would set the configuration to the new requested override
config and then proceed to update existing Resources references, which
would return immediately due to the equality check for configuration
updates.
This change pushes the setting of the new override config to the
updateResourcesForActivity method, which will properly update Resources
references that are held in the re-used DecorView.
Bug:27915587
Change-Id: I113007a40fa464b8a234b073dcf851e16fee0177
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 3477927db40933f02a5719d7cf46feba17a4257d |
|
20-Apr-2016 |
Adam Lesinski <adamlesinski@google.com> |
ResourcesManager: Throw exception if failed to load asset path
Previously if we failed to load an asset path, we would return a
null AssetManager which would lead to an immediate NPE.
Throw a proper exception instead, detailing which path failed to load.
Bug:28216288
Change-Id: I491b9316b837bf333b5ae78d4eb1ee31741617ec
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| b7e1ce07756aaca829828c2053eca0d66dd4d440 |
|
12-Apr-2016 |
Adam Lesinski <adamlesinski@google.com> |
Optimize ResTable::getLocales() to improve bindApplication performance
Change from linear searching for uniqueness to binary search.
Bug:27198799
Change-Id: I1ccb6e93cc213810848f07d631d9d8de7c719803
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 98e80076c6c4e31f04c580c8774eeea4036d32c1 |
|
15-Apr-2016 |
Tim Murray <timmurray@google.com> |
Revert "Optimize ResTable::getLocales() to improve bindApplication performance"
This reverts commit 5520581b5f043fb858b5b2044ff33ad8545a6d38.
bug 28189634
Change-Id: I2d2b859f6d9bd44434fa901cce990583f514980c
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 5520581b5f043fb858b5b2044ff33ad8545a6d38 |
|
12-Apr-2016 |
Adam Lesinski <adamlesinski@google.com> |
Optimize ResTable::getLocales() to improve bindApplication performance
Change from linear searching for uniqueness to binary search.
Bug:27198799
Change-Id: Ifa4672929df286c4693ab1f77716f08945941b0c
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 0cd9a7ea3b9812de3d013986522dd6f823adb23d |
|
01-Apr-2016 |
Adam Lesinski <adamlesinski@google.com> |
ResourcesManager: Fix a cache issue
Forgot to cache the creating of ResourcesImpl during an Activity
override config update.
Bug:27644297
Change-Id: I65d9086f6d32f5adc7231aa3a1797d4f00c4b9a9
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 7f3f49988799dc85992eedd16135515177c09dd7 |
|
30-Mar-2016 |
Adam Lesinski <adamlesinski@google.com> |
Allow multiple Resources associated with an Activity
Previously it was assumed that one Resources object per Activity would be fine.
This proved to be incorrect, as methods like Context#createConfigurationContext()
expect to create a new Resources object that gets updated whenever the Activity Resources
get updated.
To fix this issue, there exists a master override configuration for each Activity. Subsequent
Resources created for an Activity will be based off that master override configuration, and
will be updated accordingly.
Bug:27644297
Bug:27604953
Change-Id: Idb3d851f55ee7981eec4e3fe28e2ea8d55f1192d
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| c14dd78a2c20c0cfa229dfeef064de148e0b608e |
|
30-Mar-2016 |
Seigo Nonaka <nona@google.com> |
Fix incorrect initial locale negotiation.
It turned out that calling ResourceManager.setDefaultLocalesLocked
and ResourcesManager.applyConfigurationToResourcesLocked
can be called before the locale negotiation is ready.
To fix this issue, move ResourcesManager setup flow after creating
application context.
This also introduces RuntimeException for notifying developers the
initialize order.
Bug: 27567902
Change-Id: Iab7ea384b039fb649fb52d06d45b2bfae21f9a8a
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 082614c6a57a115ee0c5975e3579bf34a178c0f8 |
|
04-Mar-2016 |
Adam Lesinski <adamlesinski@google.com> |
Cache per-Activity Resources objects
Each Activity has a Resources object whose underlying state changes
when a configuration change occurs, both global and for that activity only (multi-window).
Views and other clients of the Resources object can safely cache it knowing that
they always have a reference to the most up-to-date resources.
This applies to Resources.Theme objects as well.
Bug:26854894
Change-Id: Ifd3da5a1086e17f747dfc265a447fe92a3a5c692
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| c4dd2e7d525fc41081ab9138535cd1cf153c4bc6 |
|
04-Mar-2016 |
Adam Lesinski <adamlesinski@google.com> |
Merge "Move the guts of Resources to ResourcesImpl" into nyc-dev
|
| 39bfee5e3674faea992c32204abc1c03429b8cda |
|
24-Feb-2016 |
Todd Kennedy <toddke@google.com> |
Splits without restart
In specific cases [as determined by the installer], we can install
splits without restarting the application. The split must be purely
additive [i.e. it should not modify class(es)/resource(s) defined
in the base or other splits. Otherwise, the behaviour could be
inconsistent [e.g. if a modified class was already loaded, the
modified version won't be loaded until the process is restarted].
The platform does not perform any verification that the split is
purely additive.
Bug: 26463098
Change-Id: I3526c3b1b847a8e0afabc7a4787fa770422196b7
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| fb302ccd8e0610a09691ea5503ff8111dc7a2e41 |
|
01-Mar-2016 |
Adam Lesinski <adamlesinski@google.com> |
Move the guts of Resources to ResourcesImpl
In order to satisfy the requirement that clients can
cache a Resources object when a configuration change happens,
we move the caches and all other method bodies to ResourcesImpl.
These can then be swapped out for the correct version when needed,
while allowing clients to keep holding the existing Resources references.
This is part 1 of 2 CLs. The next one will do the actual switching of implementations
based on configuration changes for multiwindow.
Bug:26854894
Change-Id: I41156194a3541e59053b4048c3a15981c7d8a506
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 834641b3908b21e7054c290e116d76e3d5e6888c |
|
24-Jan-2016 |
Roozbeh Pournader <roozbeh@google.com> |
Move locale negotiation to ResourcesManager
Previously, locale resolution happened at Resources level, which
could result in different Resources in the same app using different
locales.
This change moves the locale negotiation to ResourcesManager, which
remembers the locales supported by each Resources as they are
created, and negotiates the locale based on their union.
It also makes sure that the old model of apps getting the default
locale by accessing it through the Configuration's locale attribute
continues to work, since the negotiated locale will be moved to the
top of the list before Resources are created and when they are
updated with a Configuration change.
Bug: 25800576
Bug: 26404653
Change-Id: I0dd81df288327fd8d1229188c9544ee2209c161a
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| cada57a57bed6fb79a318ddf3cf0a09cd038c034 |
|
22-Jan-2016 |
Seigo Nonaka <nona@google.com> |
Set the default locale list when it is changed.
When the system language is changed by the Settings app, we need to call
LocaleList.setDefault() to change the default locale list
since components like TextView should be able to assume that
LocaleList.getDefault() returns the latest system locale list.
BUG: 26731035
Change-Id: I482567476e1b14cd9b4716343183627f81d96ace
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| c725e8d5ea04ffb5821e00db1c6b45cfe2130e05 |
|
31-Aug-2015 |
Alan Viverette <alanv@google.com> |
Add missing @param in ResourceManager, set InflateException source
Bug: 11695070
Change-Id: I94a4980688a952c1f59f1cb15cf2192e3c51de90
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 02fc5fef36357467eba22a0ee250a96734daf791 |
|
27-Aug-2015 |
Alan Viverette <alanv@google.com> |
Extract drawable inflation to its own class, inflate from class name
Bug: 22627299
Change-Id: Icd2ac88af4f3102e08e52f6f0f7565839da6437a
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 26698514fbac587675221149aca98f3ea6414d55 |
|
06-Jun-2015 |
Wale Ogunwale <ogunwale@google.com> |
Use DisplayAdjustments when creating display in ResourceManager
We were previous only taking the Configuration into account when
creating Display objects in the ResourceManager. This led to the
Display object not containing critical CompatibilityInfo. We now
take the entire DisplayAdjustment into account.
Bug: 21637615
Change-Id: Ide5ff49bfa12791ad17993764f312836216b1dd8
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 1dd50c54b5ca05531676e4542971b91ed023a792 |
|
16-Mar-2015 |
Adam Lesinski <adamlesinski@google.com> |
Only attempt to load .apk files in AssetManager
This will reduce the number of files we must open
and reduce log spam.
Change-Id: I595ba4a5ea8466e530915d6ae4cf1d3e3dba15ef
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base.
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 93f543ca98636a6d2552e960690294578ec37f30 |
|
18-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Fixed NPE in ResourceManager when Activity.recreate is called.
Bug: 19408756
Change-Id: I291badce7fe9a6feaf2a5e8ce1005e6a86b30147
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 7c72668f19d404b01412abc67937b1b5c660df71 |
|
07-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Adjust activity display metrics based on stack configuration.
Apps normally use context.getResources().getDisplayMetrics()
or getWindowManager().getDefaultDisplay() to get information
about the screen dimensions. Not all the screen space is available
for apps in a multi-window environment, so we limit the dimensions
of the display object exposed to the app to that of the containing
stack.
Bug: 19225079
Bug: 19354838
Change-Id: I8dc3a6c9b99ecedcca28fc4ddaba9f31feb4f871
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 60454dbc4d815c90ff2713e224953d6547fc3ad5 |
|
24-Jan-2015 |
Wale Ogunwale <ogunwale@google.com> |
Support activities in the same process having different resources.
Activities can be of various sizes in a multi-window environment.
This change allows them to have override configurations that allows
different resources to the loaded if needed.
Bug: 19002213
Change-Id: Ib2c7be0b427f5ce05e7a362bcdd496ddbc9164f0
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 54130de7d2a0827179acaa35980dbce419cb4fca |
|
20-Aug-2014 |
Adam Lesinski <adamlesinski@google.com> |
Fix crash when launching Activities in 'android' package
The LoadedApk for the 'android' package doesn't have a resource
directory set. This is fine since the AssetManager loads the
'android' package's resources by default.
This is a regression caused by https://googleplex-android-review.googlesource.com/#/c/525840/
Bug:17104110
Change-Id: I8a2158a75b4ff0e941837c11a2cb77a7aad09270
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 8a4c9721a9e09d20c63381c13fa29bd9f7cbc3e3 |
|
16-Jun-2014 |
Jeff Sharkey <jsharkey@android.com> |
Plumb split APKs into public API.
Introduces new ApplicationInfo fields to surface zero or more split
APKs for an application. Splice these APKs into both the class
loader and resource system. Cleaner building of these paths.
Run dexopt() on all split APKs found after a parse, and populate
into ApplicationInfo.
Change-Id: I4a376bf4492d84ea95aafa866e106ea43a43e492
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| de898ff42912bd7ca1bfb099cd439562496765a4 |
|
30-Jan-2014 |
Adam Lesinski <adamlesinski@google.com> |
Shared library resource support
Shared libraries can now export resources for applications
to use.
Exporting resources works the same way the framework exports
resources, by defining the public symbols in res/values/public.xml.
Building a shared library requires aapt to be invoked with the
--shared-lib option. Shared libraries will be assigned a package
ID of 0x00 at build-time. At runtime, all loaded shared libraries
will be assigned a new package ID.
Currently, shared libraries should not import other shared libraries,
as those dependencies will not be loaded at runtime.
At runtime, reflection is used to update the package ID of resource
symbols in the shared library's R class file. The package name of
the R class file is assumed to be the same as the shared library's
package name declared in its manifest. This will be customizable in
a future commit.
See /tests/SharedLibrary/ for examples of a shared library and its
client.
Bug:12724178
Change-Id: I60c0cb8ab87849f8f8a1a13431562fe8603020a7
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 48d22323ce39f9aab003dce74456889b6414af55 |
|
31-Jan-2014 |
Mårten Kongstad <marten.kongstad@sonymobile.com> |
Runtime resource overlay, iteration 2
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
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| add005cf94dcc815d29b54588c76fd87929075b3 |
|
18-Jul-2013 |
Dianne Hackborn <hackbod@google.com> |
Mmmmmmm... lovely, lovely ArrayMap.
And ArraySet, too.
Change-Id: I72ea28cbb2286b01b6e1be082f8e7ec17e99074e
/frameworks/base/core/java/android/app/ResourcesManager.java
|
| 88c0589969b17e66559cd2f132094cdaa0ee351d |
|
28-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Refactor ActivityThread cache - Baby step 1.
Introduce ResourcesManager and ResourcesKey as standalone classes.
Move DisplayMetrics and Resources HashMaps from ActivityThread to
ResourcesManager.
Change-Id: I20cc6c0dd1b74667354839e5ac9a660f4ee2d00d
/frameworks/base/core/java/android/app/ResourcesManager.java
|