101 lines
2.8 KiB
C++
Raw Normal View History

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.
*/
#include "androidfw/Chunk.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
#include "android-base/logging.h"
namespace android {
Chunk ChunkIterator::Next() {
CHECK(len_ != 0) << "called Next() after last chunk";
const ResChunk_header* this_chunk = next_chunk_;
// We've already checked the values of this_chunk, so safely increment.
next_chunk_ = reinterpret_cast<const ResChunk_header*>(
reinterpret_cast<const uint8_t*>(this_chunk) + dtohl(this_chunk->size));
len_ -= dtohl(this_chunk->size);
if (len_ != 0) {
// Prepare the next chunk.
if (VerifyNextChunkNonFatal()) {
VerifyNextChunk();
}
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 Chunk(this_chunk);
}
// TODO(b/111401637) remove this and have full resource file verification
// Returns false if there was an error.
bool ChunkIterator::VerifyNextChunkNonFatal() {
if (len_ < sizeof(ResChunk_header)) {
last_error_ = "not enough space for header";
last_error_was_fatal_ = false;
return false;
}
const size_t size = dtohl(next_chunk_->size);
if (size > len_) {
last_error_ = "chunk size is bigger than given data";
last_error_was_fatal_ = false;
return false;
}
return 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
// Returns false if there was an error.
bool ChunkIterator::VerifyNextChunk() {
const uintptr_t header_start = reinterpret_cast<uintptr_t>(next_chunk_);
// This data must be 4-byte aligned, since we directly
// access 32-bit words, which must be aligned on
// certain architectures.
if (header_start & 0x03) {
last_error_ = "header not aligned on 4-byte boundary";
return false;
}
if (len_ < sizeof(ResChunk_header)) {
last_error_ = "not enough space for header";
return false;
}
const size_t header_size = dtohs(next_chunk_->headerSize);
const size_t size = dtohl(next_chunk_->size);
if (header_size < sizeof(ResChunk_header)) {
last_error_ = "header size too small";
return false;
}
if (header_size > size) {
last_error_ = "header size is larger than entire chunk";
return false;
}
if (size > len_) {
last_error_ = "chunk size is bigger than given data";
return false;
}
if ((size | header_size) & 0x03) {
last_error_ = "header sizes are not aligned on 4-byte boundary";
return false;
}
return true;
}
} // namespace android