New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 The Android Open Source Project
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define ATRACE_TAG ATRACE_TAG_RESOURCES
|
|
|
|
|
|
|
|
#include "androidfw/AssetManager2.h"
|
|
|
|
|
2018-04-12 14:26:23 -07:00
|
|
|
#include <algorithm>
|
2017-10-16 16:18:09 -07:00
|
|
|
#include <iterator>
|
2018-10-16 12:48:38 -07:00
|
|
|
#include <map>
|
2019-01-11 11:28:34 -08:00
|
|
|
#include <set>
|
|
|
|
#include <sstream>
|
2017-01-13 20:47:26 -08:00
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
#include "android-base/logging.h"
|
|
|
|
#include "android-base/stringprintf.h"
|
|
|
|
#include "utils/ByteOrder.h"
|
|
|
|
#include "utils/Trace.h"
|
|
|
|
|
|
|
|
#ifdef _WIN32
|
|
|
|
#ifdef ERROR
|
|
|
|
#undef ERROR
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
2019-02-27 09:43:01 -08:00
|
|
|
#ifdef __ANDROID__
|
|
|
|
#define ANDROID_LOG(x) LOG(x)
|
|
|
|
#else
|
|
|
|
#define ANDROID_LOG(x) std::stringstream()
|
|
|
|
#endif
|
|
|
|
|
2017-01-16 19:11:19 -08:00
|
|
|
#include "androidfw/ResourceUtils.h"
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
namespace android {
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
struct FindEntryResult {
|
|
|
|
// A pointer to the resource table entry for this resource.
|
|
|
|
// If the size of the entry is > sizeof(ResTable_entry), it can be cast to
|
|
|
|
// a ResTable_map_entry and processed as a bag/map.
|
|
|
|
const ResTable_entry* entry;
|
|
|
|
|
|
|
|
// The configuration for which the resulting entry was defined. This is already swapped to host
|
|
|
|
// endianness.
|
|
|
|
ResTable_config config;
|
|
|
|
|
|
|
|
// The bitmask of configuration axis with which the resource value varies.
|
|
|
|
uint32_t type_flags;
|
|
|
|
|
|
|
|
// The dynamic package ID map for the package from which this resource came from.
|
|
|
|
const DynamicRefTable* dynamic_ref_table;
|
|
|
|
|
|
|
|
// The string pool reference to the type's name. This uses a different string pool than
|
|
|
|
// the global string pool, but this is hidden from the caller.
|
|
|
|
StringPoolRef type_string_ref;
|
|
|
|
|
|
|
|
// The string pool reference to the entry's name. This uses a different string pool than
|
|
|
|
// the global string pool, but this is hidden from the caller.
|
|
|
|
StringPoolRef entry_string_ref;
|
|
|
|
};
|
|
|
|
|
2017-09-25 13:21:55 -07:00
|
|
|
AssetManager2::AssetManager2() {
|
|
|
|
memset(&configuration_, 0, sizeof(configuration_));
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
|
|
|
bool AssetManager2::SetApkAssets(const std::vector<const ApkAssets*>& apk_assets,
|
2018-06-11 14:11:33 +02:00
|
|
|
bool invalidate_caches, bool filter_incompatible_configs) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
apk_assets_ = apk_assets;
|
2016-12-29 16:08:16 -05:00
|
|
|
BuildDynamicRefTable();
|
2018-06-11 14:11:33 +02:00
|
|
|
RebuildFilterList(filter_incompatible_configs);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (invalidate_caches) {
|
|
|
|
InvalidateCaches(static_cast<uint32_t>(-1));
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-12-29 16:08:16 -05:00
|
|
|
void AssetManager2::BuildDynamicRefTable() {
|
|
|
|
package_groups_.clear();
|
|
|
|
package_ids_.fill(0xff);
|
|
|
|
|
|
|
|
// 0x01 is reserved for the android package.
|
|
|
|
int next_package_id = 0x02;
|
|
|
|
const size_t apk_assets_count = apk_assets_.size();
|
|
|
|
for (size_t i = 0; i < apk_assets_count; i++) {
|
2017-09-25 13:21:55 -07:00
|
|
|
const LoadedArsc* loaded_arsc = apk_assets_[i]->GetLoadedArsc();
|
|
|
|
|
|
|
|
for (const std::unique_ptr<const LoadedPackage>& package : loaded_arsc->GetPackages()) {
|
2016-12-29 16:08:16 -05:00
|
|
|
// Get the package ID or assign one if a shared library.
|
|
|
|
int package_id;
|
|
|
|
if (package->IsDynamic()) {
|
|
|
|
package_id = next_package_id++;
|
|
|
|
} else {
|
|
|
|
package_id = package->GetPackageId();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add the mapping for package ID to index if not present.
|
|
|
|
uint8_t idx = package_ids_[package_id];
|
|
|
|
if (idx == 0xff) {
|
|
|
|
package_ids_[package_id] = idx = static_cast<uint8_t>(package_groups_.size());
|
|
|
|
package_groups_.push_back({});
|
2018-02-12 14:27:46 -08:00
|
|
|
DynamicRefTable& ref_table = package_groups_.back().dynamic_ref_table;
|
|
|
|
ref_table.mAssignedPackageId = package_id;
|
|
|
|
ref_table.mAppAsLib = package->IsDynamic() && package->GetPackageId() == 0x7f;
|
2016-12-29 16:08:16 -05:00
|
|
|
}
|
|
|
|
PackageGroup* package_group = &package_groups_[idx];
|
|
|
|
|
|
|
|
// Add the package and to the set of packages with the same ID.
|
2018-02-12 14:27:46 -08:00
|
|
|
package_group->packages_.push_back(ConfiguredPackage{package.get(), {}});
|
2016-12-29 16:08:16 -05:00
|
|
|
package_group->cookies_.push_back(static_cast<ApkAssetsCookie>(i));
|
|
|
|
|
|
|
|
// Add the package name -> build time ID mappings.
|
|
|
|
for (const DynamicPackageEntry& entry : package->GetDynamicPackageMap()) {
|
|
|
|
String16 package_name(entry.package_name.c_str(), entry.package_name.size());
|
|
|
|
package_group->dynamic_ref_table.mEntries.replaceValueFor(
|
|
|
|
package_name, static_cast<uint8_t>(entry.package_id));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now assign the runtime IDs so that we have a build-time to runtime ID map.
|
|
|
|
const auto package_groups_end = package_groups_.end();
|
|
|
|
for (auto iter = package_groups_.begin(); iter != package_groups_end; ++iter) {
|
2018-02-12 14:27:46 -08:00
|
|
|
const std::string& package_name = iter->packages_[0].loaded_package_->GetPackageName();
|
2016-12-29 16:08:16 -05:00
|
|
|
for (auto iter2 = package_groups_.begin(); iter2 != package_groups_end; ++iter2) {
|
|
|
|
iter2->dynamic_ref_table.addMapping(String16(package_name.c_str(), package_name.size()),
|
|
|
|
iter->dynamic_ref_table.mAssignedPackageId);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void AssetManager2::DumpToLog() const {
|
|
|
|
base::ScopedLogSeverity _log(base::INFO);
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
LOG(INFO) << base::StringPrintf("AssetManager2(this=%p)", this);
|
|
|
|
|
2016-12-29 16:08:16 -05:00
|
|
|
std::string list;
|
2018-02-12 14:27:46 -08:00
|
|
|
for (const auto& apk_assets : apk_assets_) {
|
|
|
|
base::StringAppendF(&list, "%s,", apk_assets->GetPath().c_str());
|
|
|
|
}
|
|
|
|
LOG(INFO) << "ApkAssets: " << list;
|
|
|
|
|
|
|
|
list = "";
|
2016-12-29 16:08:16 -05:00
|
|
|
for (size_t i = 0; i < package_ids_.size(); i++) {
|
|
|
|
if (package_ids_[i] != 0xff) {
|
2018-02-12 14:27:46 -08:00
|
|
|
base::StringAppendF(&list, "%02x -> %d, ", (int)i, package_ids_[i]);
|
2016-12-29 16:08:16 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
LOG(INFO) << "Package ID map: " << list;
|
|
|
|
|
2018-01-25 15:38:38 -08:00
|
|
|
for (const auto& package_group: package_groups_) {
|
2018-02-12 14:27:46 -08:00
|
|
|
list = "";
|
|
|
|
for (const auto& package : package_group.packages_) {
|
|
|
|
const LoadedPackage* loaded_package = package.loaded_package_;
|
|
|
|
base::StringAppendF(&list, "%s(%02x%s), ", loaded_package->GetPackageName().c_str(),
|
|
|
|
loaded_package->GetPackageId(),
|
|
|
|
(loaded_package->IsDynamic() ? " dynamic" : ""));
|
|
|
|
}
|
|
|
|
LOG(INFO) << base::StringPrintf("PG (%02x): ",
|
|
|
|
package_group.dynamic_ref_table.mAssignedPackageId)
|
|
|
|
<< list;
|
2018-11-05 15:56:15 -08:00
|
|
|
|
|
|
|
for (size_t i = 0; i < 256; i++) {
|
|
|
|
if (package_group.dynamic_ref_table.mLookupTable[i] != 0) {
|
|
|
|
LOG(INFO) << base::StringPrintf(" e[0x%02x] -> 0x%02x", (uint8_t) i,
|
|
|
|
package_group.dynamic_ref_table.mLookupTable[i]);
|
|
|
|
}
|
|
|
|
}
|
2016-12-29 16:08:16 -05:00
|
|
|
}
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
|
|
|
const ResStringPool* AssetManager2::GetStringPoolForCookie(ApkAssetsCookie cookie) const {
|
|
|
|
if (cookie < 0 || static_cast<size_t>(cookie) >= apk_assets_.size()) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
return apk_assets_[cookie]->GetLoadedArsc()->GetStringPool();
|
|
|
|
}
|
|
|
|
|
2016-12-29 16:08:16 -05:00
|
|
|
const DynamicRefTable* AssetManager2::GetDynamicRefTableForPackage(uint32_t package_id) const {
|
|
|
|
if (package_id >= package_ids_.size()) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
const size_t idx = package_ids_[package_id];
|
|
|
|
if (idx == 0xff) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
return &package_groups_[idx].dynamic_ref_table;
|
|
|
|
}
|
|
|
|
|
2017-01-23 12:58:11 -08:00
|
|
|
const DynamicRefTable* AssetManager2::GetDynamicRefTableForCookie(ApkAssetsCookie cookie) const {
|
|
|
|
for (const PackageGroup& package_group : package_groups_) {
|
|
|
|
for (const ApkAssetsCookie& package_cookie : package_group.cookies_) {
|
|
|
|
if (package_cookie == cookie) {
|
|
|
|
return &package_group.dynamic_ref_table;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2019-02-05 01:29:59 +01:00
|
|
|
const std::unordered_map<std::string, std::string>*
|
|
|
|
AssetManager2::GetOverlayableMapForPackage(uint32_t package_id) const {
|
|
|
|
|
|
|
|
if (package_id >= package_ids_.size()) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
const size_t idx = package_ids_[package_id];
|
|
|
|
if (idx == 0xff) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
const PackageGroup& package_group = package_groups_[idx];
|
|
|
|
if (package_group.packages_.size() == 0) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
const auto loaded_package = package_group.packages_[0].loaded_package_;
|
|
|
|
return &loaded_package->GetOverlayableMap();
|
|
|
|
}
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
void AssetManager2::SetConfiguration(const ResTable_config& configuration) {
|
|
|
|
const int diff = configuration_.diff(configuration);
|
|
|
|
configuration_ = configuration;
|
|
|
|
|
|
|
|
if (diff) {
|
2018-02-12 14:27:46 -08:00
|
|
|
RebuildFilterList();
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
InvalidateCaches(static_cast<uint32_t>(diff));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-13 20:47:26 -08:00
|
|
|
std::set<ResTable_config> AssetManager2::GetResourceConfigurations(bool exclude_system,
|
2018-02-12 14:27:46 -08:00
|
|
|
bool exclude_mipmap) const {
|
|
|
|
ATRACE_NAME("AssetManager::GetResourceConfigurations");
|
2017-01-13 20:47:26 -08:00
|
|
|
std::set<ResTable_config> configurations;
|
|
|
|
for (const PackageGroup& package_group : package_groups_) {
|
2018-11-30 15:22:31 -08:00
|
|
|
bool found_system_package = false;
|
2018-02-12 14:27:46 -08:00
|
|
|
for (const ConfiguredPackage& package : package_group.packages_) {
|
|
|
|
if (exclude_system && package.loaded_package_->IsSystem()) {
|
2018-11-30 15:22:31 -08:00
|
|
|
found_system_package = true;
|
2017-01-13 20:47:26 -08:00
|
|
|
continue;
|
|
|
|
}
|
2018-11-30 15:22:31 -08:00
|
|
|
|
|
|
|
if (exclude_system && package.loaded_package_->IsOverlay() && found_system_package) {
|
|
|
|
// Overlays must appear after the target package to take effect. Any overlay found in the
|
|
|
|
// same package as a system package is able to overlay system resources.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
package.loaded_package_->CollectConfigurations(exclude_mipmap, &configurations);
|
2017-01-13 20:47:26 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return configurations;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::set<std::string> AssetManager2::GetResourceLocales(bool exclude_system,
|
2018-02-12 14:27:46 -08:00
|
|
|
bool merge_equivalent_languages) const {
|
|
|
|
ATRACE_NAME("AssetManager::GetResourceLocales");
|
2017-01-13 20:47:26 -08:00
|
|
|
std::set<std::string> locales;
|
|
|
|
for (const PackageGroup& package_group : package_groups_) {
|
2018-11-30 15:22:31 -08:00
|
|
|
bool found_system_package = false;
|
2018-02-12 14:27:46 -08:00
|
|
|
for (const ConfiguredPackage& package : package_group.packages_) {
|
|
|
|
if (exclude_system && package.loaded_package_->IsSystem()) {
|
2018-11-30 15:22:31 -08:00
|
|
|
found_system_package = true;
|
2017-01-13 20:47:26 -08:00
|
|
|
continue;
|
|
|
|
}
|
2018-11-30 15:22:31 -08:00
|
|
|
|
|
|
|
if (exclude_system && package.loaded_package_->IsOverlay() && found_system_package) {
|
|
|
|
// Overlays must appear after the target package to take effect. Any overlay found in the
|
|
|
|
// same package as a system package is able to overlay system resources.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
package.loaded_package_->CollectLocales(merge_equivalent_languages, &locales);
|
2017-01-13 20:47:26 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return locales;
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
std::unique_ptr<Asset> AssetManager2::Open(const std::string& filename,
|
|
|
|
Asset::AccessMode mode) const {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
const std::string new_path = "assets/" + filename;
|
|
|
|
return OpenNonAsset(new_path, mode);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<Asset> AssetManager2::Open(const std::string& filename, ApkAssetsCookie cookie,
|
2018-02-12 14:27:46 -08:00
|
|
|
Asset::AccessMode mode) const {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
const std::string new_path = "assets/" + filename;
|
|
|
|
return OpenNonAsset(new_path, cookie, mode);
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
std::unique_ptr<AssetDir> AssetManager2::OpenDir(const std::string& dirname) const {
|
|
|
|
ATRACE_NAME("AssetManager::OpenDir");
|
2017-01-23 12:58:11 -08:00
|
|
|
|
|
|
|
std::string full_path = "assets/" + dirname;
|
|
|
|
std::unique_ptr<SortedVector<AssetDir::FileInfo>> files =
|
|
|
|
util::make_unique<SortedVector<AssetDir::FileInfo>>();
|
|
|
|
|
|
|
|
// Start from the back.
|
|
|
|
for (auto iter = apk_assets_.rbegin(); iter != apk_assets_.rend(); ++iter) {
|
|
|
|
const ApkAssets* apk_assets = *iter;
|
2019-02-21 07:54:18 +01:00
|
|
|
if (apk_assets->IsOverlay()) {
|
|
|
|
continue;
|
|
|
|
}
|
2017-01-23 12:58:11 -08:00
|
|
|
|
|
|
|
auto func = [&](const StringPiece& name, FileType type) {
|
|
|
|
AssetDir::FileInfo info;
|
|
|
|
info.setFileName(String8(name.data(), name.size()));
|
|
|
|
info.setFileType(type);
|
|
|
|
info.setSourceName(String8(apk_assets->GetPath().c_str()));
|
|
|
|
files->add(info);
|
|
|
|
};
|
|
|
|
|
|
|
|
if (!apk_assets->ForEachFile(full_path, func)) {
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<AssetDir> asset_dir = util::make_unique<AssetDir>();
|
|
|
|
asset_dir->setFileList(files.release());
|
|
|
|
return asset_dir;
|
|
|
|
}
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
// Search in reverse because that's how we used to do it and we need to preserve behaviour.
|
|
|
|
// This is unfortunate, because ClassLoaders delegate to the parent first, so the order
|
|
|
|
// is inconsistent for split APKs.
|
|
|
|
std::unique_ptr<Asset> AssetManager2::OpenNonAsset(const std::string& filename,
|
|
|
|
Asset::AccessMode mode,
|
2018-02-12 14:27:46 -08:00
|
|
|
ApkAssetsCookie* out_cookie) const {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
for (int32_t i = apk_assets_.size() - 1; i >= 0; i--) {
|
2019-02-21 07:54:18 +01:00
|
|
|
// Prevent RRO from modifying assets and other entries accessed by file
|
|
|
|
// path. Explicitly asking for a path in a given package (denoted by a
|
|
|
|
// cookie) is still OK.
|
|
|
|
if (apk_assets_[i]->IsOverlay()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
std::unique_ptr<Asset> asset = apk_assets_[i]->Open(filename, mode);
|
|
|
|
if (asset) {
|
|
|
|
if (out_cookie != nullptr) {
|
|
|
|
*out_cookie = i;
|
|
|
|
}
|
|
|
|
return asset;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (out_cookie != nullptr) {
|
|
|
|
*out_cookie = kInvalidCookie;
|
|
|
|
}
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<Asset> AssetManager2::OpenNonAsset(const std::string& filename,
|
2018-02-12 14:27:46 -08:00
|
|
|
ApkAssetsCookie cookie,
|
|
|
|
Asset::AccessMode mode) const {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (cookie < 0 || static_cast<size_t>(cookie) >= apk_assets_.size()) {
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
return apk_assets_[cookie]->Open(filename, mode);
|
|
|
|
}
|
|
|
|
|
|
|
|
ApkAssetsCookie AssetManager2::FindEntry(uint32_t resid, uint16_t density_override,
|
2018-02-12 14:27:46 -08:00
|
|
|
bool /*stop_at_first_match*/,
|
2019-01-24 10:58:23 -08:00
|
|
|
bool ignore_configuration,
|
2018-02-12 14:27:46 -08:00
|
|
|
FindEntryResult* out_entry) const {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
// Might use this if density_override != 0.
|
|
|
|
ResTable_config density_override_config;
|
|
|
|
|
|
|
|
// Select our configuration or generate a density override configuration.
|
2018-02-12 14:27:46 -08:00
|
|
|
const ResTable_config* desired_config = &configuration_;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (density_override != 0 && density_override != configuration_.density) {
|
|
|
|
density_override_config = configuration_;
|
|
|
|
density_override_config.density = density_override;
|
|
|
|
desired_config = &density_override_config;
|
|
|
|
}
|
|
|
|
|
2017-01-23 12:58:11 -08:00
|
|
|
if (!is_valid_resid(resid)) {
|
2016-12-29 16:08:16 -05:00
|
|
|
LOG(ERROR) << base::StringPrintf("Invalid ID 0x%08x.", resid);
|
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
2017-01-23 12:58:11 -08:00
|
|
|
const uint32_t package_id = get_package_id(resid);
|
|
|
|
const uint8_t type_idx = get_type_id(resid) - 1;
|
2018-02-12 14:27:46 -08:00
|
|
|
const uint16_t entry_idx = get_entry_id(resid);
|
2017-01-23 12:58:11 -08:00
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
const uint8_t package_idx = package_ids_[package_id];
|
|
|
|
if (package_idx == 0xff) {
|
2019-02-27 09:43:01 -08:00
|
|
|
ANDROID_LOG(ERROR) << base::StringPrintf("No package ID %02x found for ID 0x%08x.",
|
|
|
|
package_id, resid);
|
2016-12-29 16:08:16 -05:00
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
const PackageGroup& package_group = package_groups_[package_idx];
|
2018-02-09 11:01:45 -08:00
|
|
|
const size_t package_count = package_group.packages_.size();
|
2018-02-12 14:27:46 -08:00
|
|
|
|
|
|
|
ApkAssetsCookie best_cookie = kInvalidCookie;
|
|
|
|
const LoadedPackage* best_package = nullptr;
|
|
|
|
const ResTable_type* best_type = nullptr;
|
|
|
|
const ResTable_config* best_config = nullptr;
|
|
|
|
ResTable_config best_config_copy;
|
|
|
|
uint32_t best_offset = 0u;
|
|
|
|
uint32_t type_flags = 0u;
|
|
|
|
|
2019-01-11 11:28:34 -08:00
|
|
|
Resolution::Step::Type resolution_type;
|
|
|
|
std::vector<Resolution::Step> resolution_steps;
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
// If desired_config is the same as the set configuration, then we can use our filtered list
|
|
|
|
// and we don't need to match the configurations, since they already matched.
|
2019-01-24 10:58:23 -08:00
|
|
|
const bool use_fast_path = !ignore_configuration && desired_config == &configuration_;
|
2018-02-12 14:27:46 -08:00
|
|
|
|
|
|
|
for (size_t pi = 0; pi < package_count; pi++) {
|
|
|
|
const ConfiguredPackage& loaded_package_impl = package_group.packages_[pi];
|
|
|
|
const LoadedPackage* loaded_package = loaded_package_impl.loaded_package_;
|
|
|
|
ApkAssetsCookie cookie = package_group.cookies_[pi];
|
|
|
|
|
|
|
|
// If the type IDs are offset in this package, we need to take that into account when searching
|
|
|
|
// for a type.
|
|
|
|
const TypeSpec* type_spec = loaded_package->GetTypeSpecByTypeIndex(type_idx);
|
|
|
|
if (UNLIKELY(type_spec == nullptr)) {
|
2018-02-09 11:01:45 -08:00
|
|
|
continue;
|
2018-01-08 17:38:30 -08:00
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
uint16_t local_entry_idx = entry_idx;
|
2018-01-08 17:38:30 -08:00
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
// If there is an IDMAP supplied with this package, translate the entry ID.
|
|
|
|
if (type_spec->idmap_entries != nullptr) {
|
|
|
|
if (!LoadedIdmap::Lookup(type_spec->idmap_entries, local_entry_idx, &local_entry_idx)) {
|
|
|
|
// There is no mapping, so the resource is not meant to be in this overlay package.
|
|
|
|
continue;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
}
|
2018-02-12 14:27:46 -08:00
|
|
|
|
|
|
|
type_flags |= type_spec->GetFlagsForEntryIndex(local_entry_idx);
|
|
|
|
|
|
|
|
// If the package is an overlay, then even configurations that are the same MUST be chosen.
|
|
|
|
const bool package_is_overlay = loaded_package->IsOverlay();
|
|
|
|
|
|
|
|
if (use_fast_path) {
|
2019-01-11 11:28:34 -08:00
|
|
|
const FilteredConfigGroup& filtered_group = loaded_package_impl.filtered_configs_[type_idx];
|
2018-02-12 14:27:46 -08:00
|
|
|
const std::vector<ResTable_config>& candidate_configs = filtered_group.configurations;
|
|
|
|
const size_t type_count = candidate_configs.size();
|
|
|
|
for (uint32_t i = 0; i < type_count; i++) {
|
|
|
|
const ResTable_config& this_config = candidate_configs[i];
|
|
|
|
|
|
|
|
// We can skip calling ResTable_config::match() because we know that all candidate
|
|
|
|
// configurations that do NOT match have been filtered-out.
|
2019-01-11 11:28:34 -08:00
|
|
|
if (best_config == nullptr) {
|
|
|
|
resolution_type = Resolution::Step::Type::INITIAL;
|
|
|
|
} else if (this_config.isBetterThan(*best_config, desired_config)) {
|
|
|
|
resolution_type = Resolution::Step::Type::BETTER_MATCH;
|
|
|
|
} else if (package_is_overlay && this_config.compare(*best_config) == 0) {
|
|
|
|
resolution_type = Resolution::Step::Type::OVERLAID;
|
|
|
|
} else {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The configuration matches and is better than the previous selection.
|
|
|
|
// Find the entry value if it exists for this configuration.
|
|
|
|
const ResTable_type* type = filtered_group.types[i];
|
|
|
|
const uint32_t offset = LoadedPackage::GetEntryOffset(type, local_entry_idx);
|
|
|
|
if (offset == ResTable_type::NO_ENTRY) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
best_cookie = cookie;
|
|
|
|
best_package = loaded_package;
|
|
|
|
best_type = type;
|
|
|
|
best_config = &this_config;
|
|
|
|
best_offset = offset;
|
|
|
|
|
|
|
|
if (resource_resolution_logging_enabled_) {
|
|
|
|
resolution_steps.push_back(Resolution::Step{resolution_type,
|
|
|
|
this_config.toString(),
|
|
|
|
&loaded_package->GetPackageName()});
|
2018-02-12 14:27:46 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// This is the slower path, which doesn't use the filtered list of configurations.
|
|
|
|
// Here we must read the ResTable_config from the mmapped APK, convert it to host endianness
|
|
|
|
// and fill in any new fields that did not exist when the APK was compiled.
|
|
|
|
// Furthermore when selecting configurations we can't just record the pointer to the
|
|
|
|
// ResTable_config, we must copy it.
|
|
|
|
const auto iter_end = type_spec->types + type_spec->type_count;
|
|
|
|
for (auto iter = type_spec->types; iter != iter_end; ++iter) {
|
2019-01-24 10:58:23 -08:00
|
|
|
ResTable_config this_config{};
|
2018-02-12 14:27:46 -08:00
|
|
|
|
2019-01-24 10:58:23 -08:00
|
|
|
if (!ignore_configuration) {
|
|
|
|
this_config.copyFromDtoH((*iter)->config);
|
|
|
|
if (!this_config.match(*desired_config)) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-01-11 11:28:34 -08:00
|
|
|
|
2019-01-24 10:58:23 -08:00
|
|
|
if (best_config == nullptr) {
|
|
|
|
resolution_type = Resolution::Step::Type::INITIAL;
|
|
|
|
} else if (this_config.isBetterThan(*best_config, desired_config)) {
|
|
|
|
resolution_type = Resolution::Step::Type::BETTER_MATCH;
|
|
|
|
} else if (package_is_overlay && this_config.compare(*best_config) == 0) {
|
|
|
|
resolution_type = Resolution::Step::Type::OVERLAID;
|
|
|
|
} else {
|
|
|
|
continue;
|
|
|
|
}
|
2019-01-11 11:28:34 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
// The configuration matches and is better than the previous selection.
|
|
|
|
// Find the entry value if it exists for this configuration.
|
|
|
|
const uint32_t offset = LoadedPackage::GetEntryOffset(*iter, local_entry_idx);
|
|
|
|
if (offset == ResTable_type::NO_ENTRY) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
best_cookie = cookie;
|
|
|
|
best_package = loaded_package;
|
|
|
|
best_type = *iter;
|
|
|
|
best_config_copy = this_config;
|
|
|
|
best_config = &best_config_copy;
|
|
|
|
best_offset = offset;
|
|
|
|
|
2019-01-24 10:58:23 -08:00
|
|
|
if (ignore_configuration) {
|
|
|
|
// Any configuration will suffice, so break.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-01-11 11:28:34 -08:00
|
|
|
if (resource_resolution_logging_enabled_) {
|
|
|
|
resolution_steps.push_back(Resolution::Step{resolution_type,
|
|
|
|
this_config.toString(),
|
|
|
|
&loaded_package->GetPackageName()});
|
2018-02-12 14:27:46 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (UNLIKELY(best_cookie == kInvalidCookie)) {
|
|
|
|
return kInvalidCookie;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
const ResTable_entry* best_entry = LoadedPackage::GetEntryFromOffset(best_type, best_offset);
|
|
|
|
if (UNLIKELY(best_entry == nullptr)) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
out_entry->entry = best_entry;
|
|
|
|
out_entry->config = *best_config;
|
|
|
|
out_entry->type_flags = type_flags;
|
|
|
|
out_entry->type_string_ref = StringPoolRef(best_package->GetTypeStringPool(), best_type->id - 1);
|
|
|
|
out_entry->entry_string_ref =
|
|
|
|
StringPoolRef(best_package->GetKeyStringPool(), best_entry->key.index);
|
2016-12-29 16:08:16 -05:00
|
|
|
out_entry->dynamic_ref_table = &package_group.dynamic_ref_table;
|
2019-01-11 11:28:34 -08:00
|
|
|
|
|
|
|
if (resource_resolution_logging_enabled_) {
|
|
|
|
last_resolution.resid = resid;
|
|
|
|
last_resolution.cookie = best_cookie;
|
|
|
|
last_resolution.steps = resolution_steps;
|
|
|
|
|
|
|
|
// Cache only the type/entry refs since that's all that's needed to build name
|
|
|
|
last_resolution.type_string_ref =
|
|
|
|
StringPoolRef(best_package->GetTypeStringPool(), best_type->id - 1);
|
|
|
|
last_resolution.entry_string_ref =
|
|
|
|
StringPoolRef(best_package->GetKeyStringPool(), best_entry->key.index);
|
|
|
|
}
|
|
|
|
|
2016-12-29 16:08:16 -05:00
|
|
|
return best_cookie;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
2019-01-11 11:28:34 -08:00
|
|
|
void AssetManager2::SetResourceResolutionLoggingEnabled(bool enabled) {
|
|
|
|
resource_resolution_logging_enabled_ = enabled;
|
|
|
|
|
|
|
|
if (!enabled) {
|
|
|
|
last_resolution.cookie = kInvalidCookie;
|
|
|
|
last_resolution.resid = 0;
|
|
|
|
last_resolution.steps.clear();
|
|
|
|
last_resolution.type_string_ref = StringPoolRef();
|
|
|
|
last_resolution.entry_string_ref = StringPoolRef();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string AssetManager2::GetLastResourceResolution() const {
|
|
|
|
if (!resource_resolution_logging_enabled_) {
|
|
|
|
LOG(ERROR) << "Must enable resource resolution logging before getting path.";
|
|
|
|
return std::string();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto cookie = last_resolution.cookie;
|
|
|
|
if (cookie == kInvalidCookie) {
|
|
|
|
LOG(ERROR) << "AssetManager hasn't resolved a resource to read resolution path.";
|
|
|
|
return std::string();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t resid = last_resolution.resid;
|
|
|
|
std::vector<Resolution::Step>& steps = last_resolution.steps;
|
|
|
|
|
|
|
|
ResourceName resource_name;
|
|
|
|
std::string resource_name_string;
|
|
|
|
|
|
|
|
const LoadedPackage* package =
|
|
|
|
apk_assets_[cookie]->GetLoadedArsc()->GetPackageById(get_package_id(resid));
|
|
|
|
|
|
|
|
if (package != nullptr) {
|
|
|
|
ToResourceName(last_resolution.type_string_ref,
|
|
|
|
last_resolution.entry_string_ref,
|
2019-01-23 16:56:51 -08:00
|
|
|
package->GetPackageName(),
|
2019-01-11 11:28:34 -08:00
|
|
|
&resource_name);
|
|
|
|
resource_name_string = ToFormattedResourceString(&resource_name);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::stringstream log_stream;
|
|
|
|
log_stream << base::StringPrintf("Resolution for 0x%08x ", resid)
|
|
|
|
<< resource_name_string
|
|
|
|
<< "\n\tFor config -"
|
|
|
|
<< configuration_.toString();
|
|
|
|
|
|
|
|
std::string prefix;
|
|
|
|
for (Resolution::Step step : steps) {
|
|
|
|
switch (step.type) {
|
|
|
|
case Resolution::Step::Type::INITIAL:
|
|
|
|
prefix = "Found initial";
|
|
|
|
break;
|
|
|
|
case Resolution::Step::Type::BETTER_MATCH:
|
|
|
|
prefix = "Found better";
|
|
|
|
break;
|
|
|
|
case Resolution::Step::Type::OVERLAID:
|
|
|
|
prefix = "Overlaid";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!prefix.empty()) {
|
|
|
|
log_stream << "\n\t" << prefix << ": " << *step.package_name;
|
|
|
|
|
|
|
|
if (!step.config_name.isEmpty()) {
|
|
|
|
log_stream << " -" << step.config_name;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return log_stream.str();
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
bool AssetManager2::GetResourceName(uint32_t resid, ResourceName* out_name) const {
|
2017-10-13 15:45:34 -07:00
|
|
|
FindEntryResult entry;
|
2019-01-24 10:58:23 -08:00
|
|
|
ApkAssetsCookie cookie = FindEntry(resid, 0u /* density_override */,
|
|
|
|
true /* stop_at_first_match */,
|
|
|
|
true /* ignore_configuration */, &entry);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (cookie == kInvalidCookie) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-01-23 16:56:51 -08:00
|
|
|
const uint8_t package_idx = package_ids_[get_package_id(resid)];
|
|
|
|
if (package_idx == 0xff) {
|
|
|
|
LOG(ERROR) << base::StringPrintf("No package ID %02x found for ID 0x%08x.",
|
|
|
|
get_package_id(resid), resid);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
const PackageGroup& package_group = package_groups_[package_idx];
|
|
|
|
auto cookie_iter = std::find(package_group.cookies_.begin(),
|
|
|
|
package_group.cookies_.end(), cookie);
|
|
|
|
if (cookie_iter == package_group.cookies_.end()) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-01-23 16:56:51 -08:00
|
|
|
long package_pos = std::distance(package_group.cookies_.begin(), cookie_iter);
|
|
|
|
const LoadedPackage* package = package_group.packages_[package_pos].loaded_package_;
|
2019-01-11 11:28:34 -08:00
|
|
|
return ToResourceName(entry.type_string_ref,
|
|
|
|
entry.entry_string_ref,
|
2019-01-23 16:56:51 -08:00
|
|
|
package->GetPackageName(),
|
2019-01-11 11:28:34 -08:00
|
|
|
out_name);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
bool AssetManager2::GetResourceFlags(uint32_t resid, uint32_t* out_flags) const {
|
2017-10-13 15:45:34 -07:00
|
|
|
FindEntryResult entry;
|
2019-01-24 10:58:23 -08:00
|
|
|
ApkAssetsCookie cookie = FindEntry(resid, 0u /* density_override */,
|
|
|
|
false /* stop_at_first_match */,
|
|
|
|
true /* ignore_configuration */, &entry);
|
2017-10-13 15:45:34 -07:00
|
|
|
if (cookie != kInvalidCookie) {
|
|
|
|
*out_flags = entry.type_flags;
|
2019-01-24 10:58:23 -08:00
|
|
|
return true;
|
2017-10-13 15:45:34 -07:00
|
|
|
}
|
2019-01-24 10:58:23 -08:00
|
|
|
return false;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
ApkAssetsCookie AssetManager2::GetResource(uint32_t resid, bool may_be_bag,
|
|
|
|
uint16_t density_override, Res_value* out_value,
|
|
|
|
ResTable_config* out_selected_config,
|
2018-02-12 14:27:46 -08:00
|
|
|
uint32_t* out_flags) const {
|
2017-10-13 15:45:34 -07:00
|
|
|
FindEntryResult entry;
|
2019-01-24 10:58:23 -08:00
|
|
|
ApkAssetsCookie cookie = FindEntry(resid, density_override, false /* stop_at_first_match */,
|
|
|
|
false /* ignore_configuration */, &entry);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (cookie == kInvalidCookie) {
|
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
|
|
|
|
2017-11-29 13:24:29 -08:00
|
|
|
if (dtohs(entry.entry->flags) & ResTable_entry::FLAG_COMPLEX) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (!may_be_bag) {
|
|
|
|
LOG(ERROR) << base::StringPrintf("Resource %08x is a complex map type.", resid);
|
2017-01-13 20:47:26 -08:00
|
|
|
return kInvalidCookie;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
2017-01-13 20:47:26 -08:00
|
|
|
|
|
|
|
// Create a reference since we can't represent this complex type as a Res_value.
|
|
|
|
out_value->dataType = Res_value::TYPE_REFERENCE;
|
|
|
|
out_value->data = resid;
|
2018-02-12 14:27:46 -08:00
|
|
|
*out_selected_config = entry.config;
|
2017-10-13 15:45:34 -07:00
|
|
|
*out_flags = entry.type_flags;
|
2017-01-13 20:47:26 -08:00
|
|
|
return cookie;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
const Res_value* device_value = reinterpret_cast<const Res_value*>(
|
|
|
|
reinterpret_cast<const uint8_t*>(entry.entry) + dtohs(entry.entry->size));
|
|
|
|
out_value->copyFrom_dtoh(*device_value);
|
2016-12-29 16:08:16 -05:00
|
|
|
|
|
|
|
// Convert the package ID to the runtime assigned package ID.
|
|
|
|
entry.dynamic_ref_table->lookupResourceValue(out_value);
|
|
|
|
|
2018-02-12 14:27:46 -08:00
|
|
|
*out_selected_config = entry.config;
|
2017-10-13 15:45:34 -07:00
|
|
|
*out_flags = entry.type_flags;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
return cookie;
|
|
|
|
}
|
|
|
|
|
2017-01-13 20:47:26 -08:00
|
|
|
ApkAssetsCookie AssetManager2::ResolveReference(ApkAssetsCookie cookie, Res_value* in_out_value,
|
|
|
|
ResTable_config* in_out_selected_config,
|
|
|
|
uint32_t* in_out_flags,
|
2018-02-12 14:27:46 -08:00
|
|
|
uint32_t* out_last_reference) const {
|
2017-01-13 20:47:26 -08:00
|
|
|
constexpr const int kMaxIterations = 20;
|
|
|
|
|
|
|
|
for (size_t iteration = 0u; in_out_value->dataType == Res_value::TYPE_REFERENCE &&
|
|
|
|
in_out_value->data != 0u && iteration < kMaxIterations;
|
|
|
|
iteration++) {
|
2018-02-12 14:27:46 -08:00
|
|
|
*out_last_reference = in_out_value->data;
|
2017-01-13 20:47:26 -08:00
|
|
|
uint32_t new_flags = 0u;
|
|
|
|
cookie = GetResource(in_out_value->data, true /*may_be_bag*/, 0u /*density_override*/,
|
|
|
|
in_out_value, in_out_selected_config, &new_flags);
|
|
|
|
if (cookie == kInvalidCookie) {
|
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
|
|
|
if (in_out_flags != nullptr) {
|
|
|
|
*in_out_flags |= new_flags;
|
|
|
|
}
|
2017-01-23 12:58:11 -08:00
|
|
|
if (*out_last_reference == in_out_value->data) {
|
2017-01-13 20:47:26 -08:00
|
|
|
// This reference can't be resolved, so exit now and let the caller deal with it.
|
|
|
|
return cookie;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return cookie;
|
|
|
|
}
|
|
|
|
|
2019-01-17 17:20:10 -08:00
|
|
|
const std::vector<uint32_t> AssetManager2::GetBagResIdStack(uint32_t resid) {
|
|
|
|
auto cached_iter = cached_bag_resid_stacks_.find(resid);
|
|
|
|
if (cached_iter != cached_bag_resid_stacks_.end()) {
|
|
|
|
return cached_iter->second;
|
|
|
|
} else {
|
|
|
|
auto found_resids = std::vector<uint32_t>();
|
|
|
|
GetBag(resid, found_resids);
|
|
|
|
// Cache style stacks if they are not already cached.
|
|
|
|
cached_bag_resid_stacks_[resid] = found_resids;
|
|
|
|
return found_resids;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
const ResolvedBag* AssetManager2::GetBag(uint32_t resid) {
|
2018-04-12 14:26:23 -07:00
|
|
|
auto found_resids = std::vector<uint32_t>();
|
2019-01-17 17:20:10 -08:00
|
|
|
auto bag = GetBag(resid, found_resids);
|
|
|
|
|
|
|
|
// Cache style stacks if they are not already cached.
|
|
|
|
auto cached_iter = cached_bag_resid_stacks_.find(resid);
|
|
|
|
if (cached_iter == cached_bag_resid_stacks_.end()) {
|
|
|
|
cached_bag_resid_stacks_[resid] = found_resids;
|
|
|
|
}
|
|
|
|
return bag;
|
2018-04-12 14:26:23 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
const ResolvedBag* AssetManager2::GetBag(uint32_t resid, std::vector<uint32_t>& child_resids) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
auto cached_iter = cached_bags_.find(resid);
|
|
|
|
if (cached_iter != cached_bags_.end()) {
|
|
|
|
return cached_iter->second.get();
|
|
|
|
}
|
|
|
|
|
2017-10-13 15:45:34 -07:00
|
|
|
FindEntryResult entry;
|
2019-01-24 10:58:23 -08:00
|
|
|
ApkAssetsCookie cookie = FindEntry(resid, 0u /* density_override */,
|
|
|
|
false /* stop_at_first_match */,
|
|
|
|
false /* ignore_configuration */,
|
|
|
|
&entry);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (cookie == kInvalidCookie) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check that the size of the entry header is at least as big as
|
|
|
|
// the desired ResTable_map_entry. Also verify that the entry
|
|
|
|
// was intended to be a map.
|
|
|
|
if (dtohs(entry.entry->size) < sizeof(ResTable_map_entry) ||
|
|
|
|
(dtohs(entry.entry->flags) & ResTable_entry::FLAG_COMPLEX) == 0) {
|
|
|
|
// Not a bag, nothing to do.
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
const ResTable_map_entry* map = reinterpret_cast<const ResTable_map_entry*>(entry.entry);
|
|
|
|
const ResTable_map* map_entry =
|
|
|
|
reinterpret_cast<const ResTable_map*>(reinterpret_cast<const uint8_t*>(map) + map->size);
|
|
|
|
const ResTable_map* const map_entry_end = map_entry + dtohl(map->count);
|
|
|
|
|
2018-04-12 14:26:23 -07:00
|
|
|
// Keep track of ids that have already been seen to prevent infinite loops caused by circular
|
|
|
|
// dependencies between bags
|
|
|
|
child_resids.push_back(resid);
|
|
|
|
|
2016-12-29 16:08:16 -05:00
|
|
|
uint32_t parent_resid = dtohl(map->parent.ident);
|
2018-04-12 14:26:23 -07:00
|
|
|
if (parent_resid == 0 || std::find(child_resids.begin(), child_resids.end(), parent_resid)
|
|
|
|
!= child_resids.end()) {
|
|
|
|
// There is no parent or that a circular dependency exist, meaning there is nothing to
|
|
|
|
// inherit and we can do a simple copy of the entries in the map.
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
const size_t entry_count = map_entry_end - map_entry;
|
|
|
|
util::unique_cptr<ResolvedBag> new_bag{reinterpret_cast<ResolvedBag*>(
|
|
|
|
malloc(sizeof(ResolvedBag) + (entry_count * sizeof(ResolvedBag::Entry))))};
|
|
|
|
ResolvedBag::Entry* new_entry = new_bag->entries;
|
|
|
|
for (; map_entry != map_entry_end; ++map_entry) {
|
2016-12-29 16:08:16 -05:00
|
|
|
uint32_t new_key = dtohl(map_entry->name.ident);
|
2017-01-16 19:11:19 -08:00
|
|
|
if (!is_internal_resid(new_key)) {
|
2016-12-29 16:08:16 -05:00
|
|
|
// Attributes, arrays, etc don't have a resource id as the name. They specify
|
|
|
|
// other data, which would be wrong to change via a lookup.
|
|
|
|
if (entry.dynamic_ref_table->lookupResourceId(&new_key) != NO_ERROR) {
|
2018-02-12 14:27:46 -08:00
|
|
|
LOG(ERROR) << base::StringPrintf("Failed to resolve key 0x%08x in bag 0x%08x.", new_key,
|
|
|
|
resid);
|
2016-12-29 16:08:16 -05:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
new_entry->cookie = cookie;
|
2016-12-29 16:08:16 -05:00
|
|
|
new_entry->key = new_key;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
new_entry->key_pool = nullptr;
|
|
|
|
new_entry->type_pool = nullptr;
|
2018-11-15 15:48:28 -08:00
|
|
|
new_entry->style = resid;
|
2017-10-16 16:18:09 -07:00
|
|
|
new_entry->value.copyFrom_dtoh(map_entry->value);
|
|
|
|
status_t err = entry.dynamic_ref_table->lookupResourceValue(&new_entry->value);
|
|
|
|
if (err != NO_ERROR) {
|
|
|
|
LOG(ERROR) << base::StringPrintf(
|
|
|
|
"Failed to resolve value t=0x%02x d=0x%08x for key 0x%08x.", new_entry->value.dataType,
|
|
|
|
new_entry->value.data, new_key);
|
|
|
|
return nullptr;
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
++new_entry;
|
|
|
|
}
|
2017-10-13 15:45:34 -07:00
|
|
|
new_bag->type_spec_flags = entry.type_flags;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
new_bag->entry_count = static_cast<uint32_t>(entry_count);
|
|
|
|
ResolvedBag* result = new_bag.get();
|
|
|
|
cached_bags_[resid] = std::move(new_bag);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2016-12-29 16:08:16 -05:00
|
|
|
// In case the parent is a dynamic reference, resolve it.
|
|
|
|
entry.dynamic_ref_table->lookupResourceId(&parent_resid);
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
// Get the parent and do a merge of the keys.
|
2018-04-12 14:26:23 -07:00
|
|
|
const ResolvedBag* parent_bag = GetBag(parent_resid, child_resids);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (parent_bag == nullptr) {
|
|
|
|
// Failed to get the parent that should exist.
|
2018-02-12 14:27:46 -08:00
|
|
|
LOG(ERROR) << base::StringPrintf("Failed to find parent 0x%08x of bag 0x%08x.", parent_resid,
|
|
|
|
resid);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create the max possible entries we can make. Once we construct the bag,
|
|
|
|
// we will realloc to fit to size.
|
|
|
|
const size_t max_count = parent_bag->entry_count + dtohl(map->count);
|
2017-07-25 15:00:04 -07:00
|
|
|
util::unique_cptr<ResolvedBag> new_bag{reinterpret_cast<ResolvedBag*>(
|
|
|
|
malloc(sizeof(ResolvedBag) + (max_count * sizeof(ResolvedBag::Entry))))};
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
ResolvedBag::Entry* new_entry = new_bag->entries;
|
|
|
|
|
|
|
|
const ResolvedBag::Entry* parent_entry = parent_bag->entries;
|
|
|
|
const ResolvedBag::Entry* const parent_entry_end = parent_entry + parent_bag->entry_count;
|
|
|
|
|
|
|
|
// The keys are expected to be in sorted order. Merge the two bags.
|
|
|
|
while (map_entry != map_entry_end && parent_entry != parent_entry_end) {
|
2016-12-29 16:08:16 -05:00
|
|
|
uint32_t child_key = dtohl(map_entry->name.ident);
|
2017-01-16 19:11:19 -08:00
|
|
|
if (!is_internal_resid(child_key)) {
|
2016-12-29 16:08:16 -05:00
|
|
|
if (entry.dynamic_ref_table->lookupResourceId(&child_key) != NO_ERROR) {
|
2018-02-12 14:27:46 -08:00
|
|
|
LOG(ERROR) << base::StringPrintf("Failed to resolve key 0x%08x in bag 0x%08x.", child_key,
|
|
|
|
resid);
|
2016-12-29 16:08:16 -05:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (child_key <= parent_entry->key) {
|
|
|
|
// Use the child key if it comes before the parent
|
|
|
|
// or is equal to the parent (overrides).
|
|
|
|
new_entry->cookie = cookie;
|
|
|
|
new_entry->key = child_key;
|
|
|
|
new_entry->key_pool = nullptr;
|
|
|
|
new_entry->type_pool = nullptr;
|
2017-10-16 16:18:09 -07:00
|
|
|
new_entry->value.copyFrom_dtoh(map_entry->value);
|
2018-11-15 15:48:28 -08:00
|
|
|
new_entry->style = resid;
|
2017-10-16 16:18:09 -07:00
|
|
|
status_t err = entry.dynamic_ref_table->lookupResourceValue(&new_entry->value);
|
|
|
|
if (err != NO_ERROR) {
|
|
|
|
LOG(ERROR) << base::StringPrintf(
|
|
|
|
"Failed to resolve value t=0x%02x d=0x%08x for key 0x%08x.", new_entry->value.dataType,
|
|
|
|
new_entry->value.data, child_key);
|
|
|
|
return nullptr;
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
++map_entry;
|
|
|
|
} else {
|
|
|
|
// Take the parent entry as-is.
|
|
|
|
memcpy(new_entry, parent_entry, sizeof(*new_entry));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (child_key >= parent_entry->key) {
|
|
|
|
// Move to the next parent entry if we used it or it was overridden.
|
|
|
|
++parent_entry;
|
|
|
|
}
|
|
|
|
// Increment to the next entry to fill.
|
|
|
|
++new_entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Finish the child entries if they exist.
|
|
|
|
while (map_entry != map_entry_end) {
|
2016-12-29 16:08:16 -05:00
|
|
|
uint32_t new_key = dtohl(map_entry->name.ident);
|
2017-01-16 19:11:19 -08:00
|
|
|
if (!is_internal_resid(new_key)) {
|
2016-12-29 16:08:16 -05:00
|
|
|
if (entry.dynamic_ref_table->lookupResourceId(&new_key) != NO_ERROR) {
|
2018-02-12 14:27:46 -08:00
|
|
|
LOG(ERROR) << base::StringPrintf("Failed to resolve key 0x%08x in bag 0x%08x.", new_key,
|
|
|
|
resid);
|
2016-12-29 16:08:16 -05:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
new_entry->cookie = cookie;
|
2016-12-29 16:08:16 -05:00
|
|
|
new_entry->key = new_key;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
new_entry->key_pool = nullptr;
|
|
|
|
new_entry->type_pool = nullptr;
|
2017-10-16 16:18:09 -07:00
|
|
|
new_entry->value.copyFrom_dtoh(map_entry->value);
|
2018-11-15 15:48:28 -08:00
|
|
|
new_entry->style = resid;
|
2017-10-16 16:18:09 -07:00
|
|
|
status_t err = entry.dynamic_ref_table->lookupResourceValue(&new_entry->value);
|
|
|
|
if (err != NO_ERROR) {
|
|
|
|
LOG(ERROR) << base::StringPrintf("Failed to resolve value t=0x%02x d=0x%08x for key 0x%08x.",
|
|
|
|
new_entry->value.dataType, new_entry->value.data, new_key);
|
|
|
|
return nullptr;
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
++map_entry;
|
|
|
|
++new_entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Finish the parent entries if they exist.
|
|
|
|
if (parent_entry != parent_entry_end) {
|
|
|
|
// Take the rest of the parent entries as-is.
|
|
|
|
const size_t num_entries_to_copy = parent_entry_end - parent_entry;
|
|
|
|
memcpy(new_entry, parent_entry, num_entries_to_copy * sizeof(*new_entry));
|
|
|
|
new_entry += num_entries_to_copy;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Resize the resulting array to fit.
|
|
|
|
const size_t actual_count = new_entry - new_bag->entries;
|
|
|
|
if (actual_count != max_count) {
|
2017-07-25 15:00:04 -07:00
|
|
|
new_bag.reset(reinterpret_cast<ResolvedBag*>(realloc(
|
|
|
|
new_bag.release(), sizeof(ResolvedBag) + (actual_count * sizeof(ResolvedBag::Entry)))));
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
2017-10-13 15:45:34 -07:00
|
|
|
// Combine flags from the parent and our own bag.
|
|
|
|
new_bag->type_spec_flags = entry.type_flags | parent_bag->type_spec_flags;
|
2017-07-25 15:00:04 -07:00
|
|
|
new_bag->entry_count = static_cast<uint32_t>(actual_count);
|
|
|
|
ResolvedBag* result = new_bag.get();
|
|
|
|
cached_bags_[resid] = std::move(new_bag);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2017-01-16 19:11:19 -08:00
|
|
|
static bool Utf8ToUtf16(const StringPiece& str, std::u16string* out) {
|
|
|
|
ssize_t len =
|
|
|
|
utf8_to_utf16_length(reinterpret_cast<const uint8_t*>(str.data()), str.size(), false);
|
|
|
|
if (len < 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
out->resize(static_cast<size_t>(len));
|
|
|
|
utf8_to_utf16(reinterpret_cast<const uint8_t*>(str.data()), str.size(), &*out->begin(),
|
|
|
|
static_cast<size_t>(len + 1));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-01-13 20:47:26 -08:00
|
|
|
uint32_t AssetManager2::GetResourceId(const std::string& resource_name,
|
|
|
|
const std::string& fallback_type,
|
2018-02-12 14:27:46 -08:00
|
|
|
const std::string& fallback_package) const {
|
2017-01-16 19:11:19 -08:00
|
|
|
StringPiece package_name, type, entry;
|
|
|
|
if (!ExtractResourceName(resource_name, &package_name, &type, &entry)) {
|
|
|
|
return 0u;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (entry.empty()) {
|
|
|
|
return 0u;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (package_name.empty()) {
|
|
|
|
package_name = fallback_package;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type.empty()) {
|
|
|
|
type = fallback_type;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::u16string type16;
|
|
|
|
if (!Utf8ToUtf16(type, &type16)) {
|
|
|
|
return 0u;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::u16string entry16;
|
|
|
|
if (!Utf8ToUtf16(entry, &entry16)) {
|
|
|
|
return 0u;
|
|
|
|
}
|
|
|
|
|
|
|
|
const StringPiece16 kAttr16 = u"attr";
|
|
|
|
const static std::u16string kAttrPrivate16 = u"^attr-private";
|
|
|
|
|
|
|
|
for (const PackageGroup& package_group : package_groups_) {
|
2018-02-12 14:27:46 -08:00
|
|
|
for (const ConfiguredPackage& package_impl : package_group.packages_) {
|
|
|
|
const LoadedPackage* package = package_impl.loaded_package_;
|
2017-01-16 19:11:19 -08:00
|
|
|
if (package_name != package->GetPackageName()) {
|
|
|
|
// All packages in the same group are expected to have the same package name.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t resid = package->FindEntryByName(type16, entry16);
|
|
|
|
if (resid == 0u && kAttr16 == type16) {
|
|
|
|
// Private attributes in libraries (such as the framework) are sometimes encoded
|
|
|
|
// under the type '^attr-private' in order to leave the ID space of public 'attr'
|
|
|
|
// free for future additions. Check '^attr-private' for the same name.
|
|
|
|
resid = package->FindEntryByName(kAttrPrivate16, entry16);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (resid != 0u) {
|
|
|
|
return fix_package_id(resid, package_group.dynamic_ref_table.mAssignedPackageId);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-01-13 20:47:26 -08:00
|
|
|
return 0u;
|
|
|
|
}
|
|
|
|
|
2018-06-11 14:11:33 +02:00
|
|
|
void AssetManager2::RebuildFilterList(bool filter_incompatible_configs) {
|
2018-02-12 14:27:46 -08:00
|
|
|
for (PackageGroup& group : package_groups_) {
|
|
|
|
for (ConfiguredPackage& impl : group.packages_) {
|
|
|
|
// Destroy it.
|
|
|
|
impl.filtered_configs_.~ByteBucketArray();
|
|
|
|
|
|
|
|
// Re-create it.
|
|
|
|
new (&impl.filtered_configs_) ByteBucketArray<FilteredConfigGroup>();
|
|
|
|
|
|
|
|
// Create the filters here.
|
|
|
|
impl.loaded_package_->ForEachTypeSpec([&](const TypeSpec* spec, uint8_t type_index) {
|
|
|
|
FilteredConfigGroup& group = impl.filtered_configs_.editItemAt(type_index);
|
|
|
|
const auto iter_end = spec->types + spec->type_count;
|
|
|
|
for (auto iter = spec->types; iter != iter_end; ++iter) {
|
|
|
|
ResTable_config this_config;
|
|
|
|
this_config.copyFromDtoH((*iter)->config);
|
2018-06-11 14:11:33 +02:00
|
|
|
if (!filter_incompatible_configs || this_config.match(configuration_)) {
|
2018-02-12 14:27:46 -08:00
|
|
|
group.configurations.push_back(this_config);
|
|
|
|
group.types.push_back(*iter);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
void AssetManager2::InvalidateCaches(uint32_t diff) {
|
2019-03-04 09:41:00 -08:00
|
|
|
cached_bag_resid_stacks_.clear();
|
|
|
|
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (diff == 0xffffffffu) {
|
|
|
|
// Everything must go.
|
|
|
|
cached_bags_.clear();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Be more conservative with what gets purged. Only if the bag has other possible
|
|
|
|
// variations with respect to what changed (diff) should we remove it.
|
|
|
|
for (auto iter = cached_bags_.cbegin(); iter != cached_bags_.cend();) {
|
|
|
|
if (diff & iter->second->type_spec_flags) {
|
|
|
|
iter = cached_bags_.erase(iter);
|
|
|
|
} else {
|
|
|
|
++iter;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-16 12:48:38 -07:00
|
|
|
uint8_t AssetManager2::GetAssignedPackageId(const LoadedPackage* package) {
|
|
|
|
for (auto& package_group : package_groups_) {
|
|
|
|
for (auto& package2 : package_group.packages_) {
|
|
|
|
if (package2.loaded_package_ == package) {
|
|
|
|
return package_group.dynamic_ref_table.mAssignedPackageId;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-16 16:18:09 -07:00
|
|
|
std::unique_ptr<Theme> AssetManager2::NewTheme() {
|
|
|
|
return std::unique_ptr<Theme>(new Theme(this));
|
|
|
|
}
|
|
|
|
|
|
|
|
Theme::Theme(AssetManager2* asset_manager) : asset_manager_(asset_manager) {
|
|
|
|
}
|
|
|
|
|
|
|
|
Theme::~Theme() = default;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
struct ThemeEntry {
|
|
|
|
ApkAssetsCookie cookie;
|
|
|
|
uint32_t type_spec_flags;
|
|
|
|
Res_value value;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ThemeType {
|
|
|
|
int entry_count;
|
|
|
|
ThemeEntry entries[0];
|
|
|
|
};
|
|
|
|
|
|
|
|
constexpr size_t kTypeCount = std::numeric_limits<uint8_t>::max() + 1;
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
struct Theme::Package {
|
|
|
|
// Each element of Type will be a dynamically sized object
|
|
|
|
// allocated to have the entries stored contiguously with the Type.
|
|
|
|
std::array<util::unique_cptr<ThemeType>, kTypeCount> types;
|
|
|
|
};
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
|
|
|
bool Theme::ApplyStyle(uint32_t resid, bool force) {
|
2018-02-12 14:27:46 -08:00
|
|
|
ATRACE_NAME("Theme::ApplyStyle");
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
|
|
|
const ResolvedBag* bag = asset_manager_->GetBag(resid);
|
|
|
|
if (bag == nullptr) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Merge the flags from this style.
|
|
|
|
type_spec_flags_ |= bag->type_spec_flags;
|
|
|
|
|
2017-10-16 16:18:09 -07:00
|
|
|
int last_type_idx = -1;
|
|
|
|
int last_package_idx = -1;
|
|
|
|
Package* last_package = nullptr;
|
|
|
|
ThemeType* last_type = nullptr;
|
|
|
|
|
|
|
|
// Iterate backwards, because each bag is sorted in ascending key ID order, meaning we will only
|
|
|
|
// need to perform one resize per type.
|
|
|
|
using reverse_bag_iterator = std::reverse_iterator<const ResolvedBag::Entry*>;
|
|
|
|
const auto bag_iter_end = reverse_bag_iterator(begin(bag));
|
|
|
|
for (auto bag_iter = reverse_bag_iterator(end(bag)); bag_iter != bag_iter_end; ++bag_iter) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
const uint32_t attr_resid = bag_iter->key;
|
|
|
|
|
2017-10-16 16:18:09 -07:00
|
|
|
// If the resource ID passed in is not a style, the key can be some other identifier that is not
|
|
|
|
// a resource ID. We should fail fast instead of operating with strange resource IDs.
|
2017-01-16 19:11:19 -08:00
|
|
|
if (!is_valid_resid(attr_resid)) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-10-16 16:18:09 -07:00
|
|
|
// We don't use the 0-based index for the type so that we can avoid doing ID validation
|
|
|
|
// upon lookup. Instead, we keep space for the type ID 0 in our data structures. Since
|
|
|
|
// the construction of this type is guarded with a resource ID check, it will never be
|
|
|
|
// populated, and querying type ID 0 will always fail.
|
|
|
|
const int package_idx = get_package_id(attr_resid);
|
|
|
|
const int type_idx = get_type_id(attr_resid);
|
|
|
|
const int entry_idx = get_entry_id(attr_resid);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
2017-10-16 16:18:09 -07:00
|
|
|
if (last_package_idx != package_idx) {
|
|
|
|
std::unique_ptr<Package>& package = packages_[package_idx];
|
|
|
|
if (package == nullptr) {
|
|
|
|
package.reset(new Package());
|
|
|
|
}
|
|
|
|
last_package_idx = package_idx;
|
|
|
|
last_package = package.get();
|
|
|
|
last_type_idx = -1;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
2017-10-16 16:18:09 -07:00
|
|
|
if (last_type_idx != type_idx) {
|
|
|
|
util::unique_cptr<ThemeType>& type = last_package->types[type_idx];
|
|
|
|
if (type == nullptr) {
|
|
|
|
// Allocate enough memory to contain this entry_idx. Since we're iterating in reverse over
|
|
|
|
// a sorted list of attributes, this shouldn't be resized again during this method call.
|
|
|
|
type.reset(reinterpret_cast<ThemeType*>(
|
|
|
|
calloc(sizeof(ThemeType) + (entry_idx + 1) * sizeof(ThemeEntry), 1)));
|
|
|
|
type->entry_count = entry_idx + 1;
|
|
|
|
} else if (entry_idx >= type->entry_count) {
|
|
|
|
// Reallocate the memory to contain this entry_idx. Since we're iterating in reverse over
|
|
|
|
// a sorted list of attributes, this shouldn't be resized again during this method call.
|
|
|
|
const int new_count = entry_idx + 1;
|
|
|
|
type.reset(reinterpret_cast<ThemeType*>(
|
|
|
|
realloc(type.release(), sizeof(ThemeType) + (new_count * sizeof(ThemeEntry)))));
|
|
|
|
|
|
|
|
// Clear out the newly allocated space (which isn't zeroed).
|
|
|
|
memset(type->entries + type->entry_count, 0,
|
|
|
|
(new_count - type->entry_count) * sizeof(ThemeEntry));
|
|
|
|
type->entry_count = new_count;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
2017-10-16 16:18:09 -07:00
|
|
|
last_type_idx = type_idx;
|
|
|
|
last_type = type.get();
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
2017-10-16 16:18:09 -07:00
|
|
|
|
|
|
|
ThemeEntry& entry = last_type->entries[entry_idx];
|
|
|
|
if (force || (entry.value.dataType == Res_value::TYPE_NULL &&
|
|
|
|
entry.value.data != Res_value::DATA_NULL_EMPTY)) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
entry.cookie = bag_iter->cookie;
|
|
|
|
entry.type_spec_flags |= bag->type_spec_flags;
|
|
|
|
entry.value = bag_iter->value;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
ApkAssetsCookie Theme::GetAttribute(uint32_t resid, Res_value* out_value,
|
|
|
|
uint32_t* out_flags) const {
|
2017-10-16 16:18:09 -07:00
|
|
|
int cnt = 20;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
|
|
|
uint32_t type_spec_flags = 0u;
|
|
|
|
|
2017-10-16 16:18:09 -07:00
|
|
|
do {
|
|
|
|
const int package_idx = get_package_id(resid);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
const Package* package = packages_[package_idx].get();
|
2017-10-16 16:18:09 -07:00
|
|
|
if (package != nullptr) {
|
|
|
|
// The themes are constructed with a 1-based type ID, so no need to decrement here.
|
|
|
|
const int type_idx = get_type_id(resid);
|
|
|
|
const ThemeType* type = package->types[type_idx].get();
|
|
|
|
if (type != nullptr) {
|
|
|
|
const int entry_idx = get_entry_id(resid);
|
|
|
|
if (entry_idx < type->entry_count) {
|
|
|
|
const ThemeEntry& entry = type->entries[entry_idx];
|
|
|
|
type_spec_flags |= entry.type_spec_flags;
|
|
|
|
|
|
|
|
if (entry.value.dataType == Res_value::TYPE_ATTRIBUTE) {
|
|
|
|
if (cnt > 0) {
|
|
|
|
cnt--;
|
|
|
|
resid = entry.value.data;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
|
|
|
|
|
|
|
// @null is different than @empty.
|
|
|
|
if (entry.value.dataType == Res_value::TYPE_NULL &&
|
|
|
|
entry.value.data != Res_value::DATA_NULL_EMPTY) {
|
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
|
|
|
|
|
|
|
*out_value = entry.value;
|
2016-12-29 16:08:16 -05:00
|
|
|
*out_flags = type_spec_flags;
|
2017-10-16 16:18:09 -07:00
|
|
|
return entry.cookie;
|
2016-12-29 16:08:16 -05:00
|
|
|
}
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
2017-10-16 16:18:09 -07:00
|
|
|
break;
|
|
|
|
} while (true);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
2017-01-23 12:58:11 -08:00
|
|
|
|
|
|
|
ApkAssetsCookie Theme::ResolveAttributeReference(ApkAssetsCookie cookie, Res_value* in_out_value,
|
|
|
|
ResTable_config* in_out_selected_config,
|
|
|
|
uint32_t* in_out_type_spec_flags,
|
2018-02-12 14:27:46 -08:00
|
|
|
uint32_t* out_last_ref) const {
|
2017-01-23 12:58:11 -08:00
|
|
|
if (in_out_value->dataType == Res_value::TYPE_ATTRIBUTE) {
|
|
|
|
uint32_t new_flags;
|
|
|
|
cookie = GetAttribute(in_out_value->data, in_out_value, &new_flags);
|
|
|
|
if (cookie == kInvalidCookie) {
|
|
|
|
return kInvalidCookie;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (in_out_type_spec_flags != nullptr) {
|
|
|
|
*in_out_type_spec_flags |= new_flags;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return asset_manager_->ResolveReference(cookie, in_out_value, in_out_selected_config,
|
|
|
|
in_out_type_spec_flags, out_last_ref);
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
|
|
|
void Theme::Clear() {
|
|
|
|
type_spec_flags_ = 0u;
|
|
|
|
for (std::unique_ptr<Package>& package : packages_) {
|
|
|
|
package.reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-16 12:48:38 -07:00
|
|
|
void Theme::SetTo(const Theme& o) {
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (this == &o) {
|
2018-10-16 12:48:38 -07:00
|
|
|
return;
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
type_spec_flags_ = o.type_spec_flags_;
|
|
|
|
|
2018-10-16 12:48:38 -07:00
|
|
|
if (asset_manager_ == o.asset_manager_) {
|
|
|
|
// The theme comes from the same asset manager so all theme data can be copied exactly
|
|
|
|
for (size_t p = 0; p < packages_.size(); p++) {
|
|
|
|
const Package *package = o.packages_[p].get();
|
|
|
|
if (package == nullptr) {
|
|
|
|
// The other theme doesn't have this package, clear ours.
|
|
|
|
packages_[p].reset();
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (packages_[p] == nullptr) {
|
|
|
|
// The other theme has this package, but we don't. Make one.
|
|
|
|
packages_[p].reset(new Package());
|
|
|
|
}
|
2017-09-25 13:10:14 -07:00
|
|
|
|
2018-10-16 12:48:38 -07:00
|
|
|
for (size_t t = 0; t < package->types.size(); t++) {
|
|
|
|
const ThemeType *type = package->types[t].get();
|
|
|
|
if (type == nullptr) {
|
|
|
|
// The other theme doesn't have this type, clear ours.
|
|
|
|
packages_[p]->types[t].reset();
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create a new type and update it to theirs.
|
|
|
|
const size_t type_alloc_size = sizeof(ThemeType) + (type->entry_count * sizeof(ThemeEntry));
|
|
|
|
void *copied_data = malloc(type_alloc_size);
|
|
|
|
memcpy(copied_data, type, type_alloc_size);
|
|
|
|
packages_[p]->types[t].reset(reinterpret_cast<ThemeType *>(copied_data));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
std::map<ApkAssetsCookie, ApkAssetsCookie> src_to_dest_asset_cookies;
|
|
|
|
typedef std::map<int, int> SourceToDestinationRuntimePackageMap;
|
|
|
|
std::map<ApkAssetsCookie, SourceToDestinationRuntimePackageMap> src_asset_cookie_id_map;
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
// Determine which ApkAssets are loaded in both theme AssetManagers.
|
2018-10-16 12:48:38 -07:00
|
|
|
std::vector<const ApkAssets*> src_assets = o.asset_manager_->GetApkAssets();
|
|
|
|
for (size_t i = 0; i < src_assets.size(); i++) {
|
|
|
|
const ApkAssets* src_asset = src_assets[i];
|
|
|
|
|
|
|
|
std::vector<const ApkAssets*> dest_assets = asset_manager_->GetApkAssets();
|
|
|
|
for (size_t j = 0; j < dest_assets.size(); j++) {
|
|
|
|
const ApkAssets* dest_asset = dest_assets[j];
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
// Map the runtime package of the source apk asset to the destination apk asset.
|
2018-10-16 12:48:38 -07:00
|
|
|
if (src_asset->GetPath() == dest_asset->GetPath()) {
|
|
|
|
const std::vector<std::unique_ptr<const LoadedPackage>>& src_packages =
|
|
|
|
src_asset->GetLoadedArsc()->GetPackages();
|
|
|
|
const std::vector<std::unique_ptr<const LoadedPackage>>& dest_packages =
|
|
|
|
dest_asset->GetLoadedArsc()->GetPackages();
|
|
|
|
|
|
|
|
SourceToDestinationRuntimePackageMap package_map;
|
|
|
|
|
|
|
|
// The source and destination package should have the same number of packages loaded in
|
|
|
|
// the same order.
|
|
|
|
const size_t N = src_packages.size();
|
|
|
|
CHECK(N == dest_packages.size())
|
|
|
|
<< " LoadedArsc " << src_asset->GetPath() << " differs number of packages.";
|
|
|
|
for (size_t p = 0; p < N; p++) {
|
|
|
|
auto& src_package = src_packages[p];
|
|
|
|
auto& dest_package = dest_packages[p];
|
|
|
|
CHECK(src_package->GetPackageName() == dest_package->GetPackageName())
|
|
|
|
<< " Package " << src_package->GetPackageName() << " differs in load order.";
|
|
|
|
|
|
|
|
int src_package_id = o.asset_manager_->GetAssignedPackageId(src_package.get());
|
|
|
|
int dest_package_id = asset_manager_->GetAssignedPackageId(dest_package.get());
|
|
|
|
package_map[src_package_id] = dest_package_id;
|
|
|
|
}
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
src_to_dest_asset_cookies.insert(std::make_pair(i, j));
|
|
|
|
src_asset_cookie_id_map.insert(std::make_pair(i, package_map));
|
2018-10-16 12:48:38 -07:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
// Reset the data in the destination theme.
|
2018-10-16 12:48:38 -07:00
|
|
|
for (size_t p = 0; p < packages_.size(); p++) {
|
|
|
|
if (packages_[p] != nullptr) {
|
|
|
|
packages_[p].reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (size_t p = 0; p < packages_.size(); p++) {
|
|
|
|
const Package *package = o.packages_[p].get();
|
|
|
|
if (package == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (size_t t = 0; t < package->types.size(); t++) {
|
|
|
|
const ThemeType *type = package->types[t].get();
|
|
|
|
if (type == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (size_t e = 0; e < type->entry_count; e++) {
|
|
|
|
const ThemeEntry &entry = type->entries[e];
|
|
|
|
if (entry.value.dataType == Res_value::TYPE_NULL &&
|
|
|
|
entry.value.data != Res_value::DATA_NULL_EMPTY) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
bool is_reference = (entry.value.dataType == Res_value::TYPE_ATTRIBUTE
|
|
|
|
|| entry.value.dataType == Res_value::TYPE_REFERENCE
|
|
|
|
|| entry.value.dataType == Res_value::TYPE_DYNAMIC_ATTRIBUTE
|
|
|
|
|| entry.value.dataType == Res_value::TYPE_DYNAMIC_REFERENCE)
|
|
|
|
&& entry.value.data != 0x0;
|
|
|
|
|
2018-11-19 12:11:38 -08:00
|
|
|
// If the attribute value represents an attribute or reference, the package id of the
|
2019-03-08 17:26:28 -08:00
|
|
|
// value needs to be rewritten to the package id of the value in the destination.
|
|
|
|
uint32_t attribute_data = entry.value.data;
|
|
|
|
if (is_reference) {
|
|
|
|
// Determine the package id of the reference in the destination AssetManager.
|
2018-11-19 12:11:38 -08:00
|
|
|
auto value_package_map = src_asset_cookie_id_map.find(entry.cookie);
|
|
|
|
if (value_package_map == src_asset_cookie_id_map.end()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto value_dest_package = value_package_map->second.find(
|
|
|
|
get_package_id(entry.value.data));
|
|
|
|
if (value_dest_package == value_package_map->second.end()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
attribute_data = fix_package_id(entry.value.data, value_dest_package->second);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Find the cookie of the value in the destination. If the source apk is not loaded in the
|
|
|
|
// destination, only copy resources that do not reference resources in the source.
|
|
|
|
ApkAssetsCookie data_dest_cookie;
|
|
|
|
auto value_dest_cookie = src_to_dest_asset_cookies.find(entry.cookie);
|
|
|
|
if (value_dest_cookie != src_to_dest_asset_cookies.end()) {
|
|
|
|
data_dest_cookie = value_dest_cookie->second;
|
|
|
|
} else {
|
|
|
|
if (is_reference || entry.value.dataType == Res_value::TYPE_STRING) {
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
data_dest_cookie = 0x0;
|
|
|
|
}
|
2018-11-19 12:11:38 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
// The package id of the attribute needs to be rewritten to the package id of the
|
2019-03-08 17:26:28 -08:00
|
|
|
// attribute in the destination.
|
2018-10-16 12:48:38 -07:00
|
|
|
int attribute_dest_package_id = p;
|
|
|
|
if (attribute_dest_package_id != 0x01) {
|
2019-03-08 17:26:28 -08:00
|
|
|
// Find the cookie of the attribute resource id in the source AssetManager
|
2018-10-16 12:48:38 -07:00
|
|
|
FindEntryResult attribute_entry_result;
|
|
|
|
ApkAssetsCookie attribute_cookie =
|
2019-01-24 10:58:23 -08:00
|
|
|
o.asset_manager_->FindEntry(make_resid(p, t, e), 0 /* density_override */ ,
|
|
|
|
true /* stop_at_first_match */,
|
|
|
|
true /* ignore_configuration */,
|
2018-10-16 12:48:38 -07:00
|
|
|
&attribute_entry_result);
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
// Determine the package id of the attribute in the destination AssetManager.
|
2018-10-16 12:48:38 -07:00
|
|
|
auto attribute_package_map = src_asset_cookie_id_map.find(attribute_cookie);
|
|
|
|
if (attribute_package_map == src_asset_cookie_id_map.end()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
auto attribute_dest_package = attribute_package_map->second.find(
|
|
|
|
attribute_dest_package_id);
|
|
|
|
if (attribute_dest_package == attribute_package_map->second.end()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
attribute_dest_package_id = attribute_dest_package->second;
|
|
|
|
}
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
// Lazily instantiate the destination package.
|
2018-10-16 12:48:38 -07:00
|
|
|
std::unique_ptr<Package>& dest_package = packages_[attribute_dest_package_id];
|
|
|
|
if (dest_package == nullptr) {
|
|
|
|
dest_package.reset(new Package());
|
|
|
|
}
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
// Lazily instantiate and resize the destination type.
|
2018-10-16 12:48:38 -07:00
|
|
|
util::unique_cptr<ThemeType>& dest_type = dest_package->types[t];
|
|
|
|
if (dest_type == nullptr || dest_type->entry_count < type->entry_count) {
|
|
|
|
const size_t type_alloc_size = sizeof(ThemeType)
|
|
|
|
+ (type->entry_count * sizeof(ThemeEntry));
|
|
|
|
void* dest_data = malloc(type_alloc_size);
|
|
|
|
memset(dest_data, 0, type->entry_count * sizeof(ThemeEntry));
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
// Copy the existing destination type values if the type is resized.
|
2018-10-16 12:48:38 -07:00
|
|
|
if (dest_type != nullptr) {
|
|
|
|
memcpy(dest_data, type, sizeof(ThemeType)
|
|
|
|
+ (dest_type->entry_count * sizeof(ThemeEntry)));
|
|
|
|
}
|
|
|
|
|
|
|
|
dest_type.reset(reinterpret_cast<ThemeType *>(dest_data));
|
|
|
|
dest_type->entry_count = type->entry_count;
|
|
|
|
}
|
|
|
|
|
2019-03-08 17:26:28 -08:00
|
|
|
dest_type->entries[e].cookie = data_dest_cookie;
|
2018-10-16 12:48:38 -07:00
|
|
|
dest_type->entries[e].value.dataType = entry.value.dataType;
|
2019-03-08 17:26:28 -08:00
|
|
|
dest_type->entries[e].value.data = attribute_data;
|
2018-10-16 12:48:38 -07:00
|
|
|
dest_type->entries[e].type_spec_flags = entry.type_spec_flags;
|
|
|
|
}
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
2018-10-16 12:48:38 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Theme::Dump() const {
|
|
|
|
base::ScopedLogSeverity _log(base::INFO);
|
|
|
|
LOG(INFO) << base::StringPrintf("Theme(this=%p, AssetManager2=%p)", this, asset_manager_);
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
|
2018-10-16 12:48:38 -07:00
|
|
|
for (int p = 0; p < packages_.size(); p++) {
|
|
|
|
auto& package = packages_[p];
|
|
|
|
if (package == nullptr) {
|
|
|
|
continue;
|
2017-09-25 13:10:14 -07:00
|
|
|
}
|
|
|
|
|
2018-10-16 12:48:38 -07:00
|
|
|
for (int t = 0; t < package->types.size(); t++) {
|
|
|
|
auto& type = package->types[t];
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
if (type == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-10-16 12:48:38 -07:00
|
|
|
for (int e = 0; e < type->entry_count; e++) {
|
|
|
|
auto& entry = type->entries[e];
|
|
|
|
if (entry.value.dataType == Res_value::TYPE_NULL &&
|
|
|
|
entry.value.data != Res_value::DATA_NULL_EMPTY) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
LOG(INFO) << base::StringPrintf(" entry(0x%08x)=(0x%08x) type=(0x%02x), cookie(%d)",
|
|
|
|
make_resid(p, t, e), entry.value.data,
|
|
|
|
entry.value.dataType, entry.cookie);
|
|
|
|
}
|
New implementation of AssetManager/ResTable
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
2016-10-28 16:39:15 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace android
|