2016-12-01 15:55:00 -08:00
|
|
|
// Copyright (C) 2010 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.
|
|
|
|
|
|
|
|
// libandroidfw is partially built for the host (used by obbtool, aapt, and others)
|
|
|
|
|
2021-02-12 17:07:05 -08:00
|
|
|
package {
|
|
|
|
default_applicable_licenses: ["frameworks_base_libs_androidfw_license"],
|
|
|
|
}
|
|
|
|
|
|
|
|
// Added automatically by a large-scale-change
|
|
|
|
// See: http://go/android-license-faq
|
|
|
|
license {
|
|
|
|
name: "frameworks_base_libs_androidfw_license",
|
|
|
|
visibility: [":__subpackages__"],
|
|
|
|
license_kinds: [
|
|
|
|
"SPDX-license-identifier-Apache-2.0",
|
|
|
|
],
|
|
|
|
license_text: [
|
|
|
|
"NOTICE",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
|
2017-10-11 16:50:37 -07:00
|
|
|
cc_defaults {
|
|
|
|
name: "libandroidfw_defaults",
|
2016-12-01 15:55:00 -08:00
|
|
|
cflags: [
|
|
|
|
"-Werror",
|
|
|
|
"-Wunreachable-code",
|
|
|
|
],
|
2017-10-11 16:50:37 -07:00
|
|
|
target: {
|
|
|
|
windows: {
|
|
|
|
// The Windows compiler warns incorrectly for value initialization with {}.
|
|
|
|
cppflags: ["-Wno-missing-field-initializers"],
|
|
|
|
},
|
|
|
|
host: {
|
|
|
|
cflags: ["-DSTATIC_ANDROIDFW_FOR_TOOLS"],
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libandroidfw",
|
|
|
|
defaults: ["libandroidfw_defaults"],
|
|
|
|
host_supported: true,
|
2016-12-01 15:55:00 -08:00
|
|
|
srcs: [
|
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
|
|
|
"ApkAssets.cpp",
|
2016-12-01 15:55:00 -08:00
|
|
|
"Asset.cpp",
|
|
|
|
"AssetDir.cpp",
|
|
|
|
"AssetManager.cpp",
|
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
|
|
|
"AssetManager2.cpp",
|
2021-01-10 08:36:36 -08:00
|
|
|
"AssetsProvider.cpp",
|
2016-12-01 15:55:00 -08:00
|
|
|
"AttributeResolution.cpp",
|
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
|
|
|
"ChunkIterator.cpp",
|
2018-06-20 08:46:41 +02:00
|
|
|
"ConfigDescription.cpp",
|
2017-09-25 13:21:55 -07:00
|
|
|
"Idmap.cpp",
|
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
|
|
|
"LoadedArsc.cpp",
|
2018-06-20 08:46:41 +02:00
|
|
|
"Locale.cpp",
|
2016-12-01 15:55:00 -08:00
|
|
|
"LocaleData.cpp",
|
|
|
|
"misc.cpp",
|
|
|
|
"ObbFile.cpp",
|
2018-09-27 13:32:30 +02:00
|
|
|
"PosixUtils.cpp",
|
2016-12-01 15:55:00 -08:00
|
|
|
"ResourceTypes.cpp",
|
2017-01-16 19:11:19 -08:00
|
|
|
"ResourceUtils.cpp",
|
2016-12-01 15:55:00 -08:00
|
|
|
"StreamingZipInflater.cpp",
|
|
|
|
"TypeWrappers.cpp",
|
2016-12-29 16:08:16 -05:00
|
|
|
"Util.cpp",
|
2016-12-01 15:55:00 -08:00
|
|
|
"ZipFileRO.cpp",
|
|
|
|
"ZipUtils.cpp",
|
|
|
|
],
|
|
|
|
export_include_dirs: ["include"],
|
2018-05-09 20:30:33 -07:00
|
|
|
export_shared_lib_headers: ["libz"],
|
2020-11-16 23:08:18 +00:00
|
|
|
static_libs: ["libincfs-utils"],
|
|
|
|
whole_static_libs: ["libincfs-utils"],
|
|
|
|
export_static_lib_headers: ["libincfs-utils"],
|
2016-12-01 15:55:00 -08:00
|
|
|
target: {
|
|
|
|
android: {
|
|
|
|
srcs: [
|
|
|
|
"BackupData.cpp",
|
|
|
|
"BackupHelpers.cpp",
|
|
|
|
"CursorWindow.cpp",
|
|
|
|
],
|
|
|
|
shared_libs: [
|
|
|
|
"libbase",
|
|
|
|
"libbinder",
|
|
|
|
"liblog",
|
|
|
|
"libcutils",
|
2020-11-16 23:08:18 +00:00
|
|
|
"libincfs",
|
2016-12-01 15:55:00 -08:00
|
|
|
"libutils",
|
|
|
|
"libz",
|
|
|
|
],
|
2021-02-26 03:53:04 -05:00
|
|
|
static_libs: ["libziparchive_for_incfs"],
|
2016-12-01 15:55:00 -08:00
|
|
|
static: {
|
|
|
|
enabled: false,
|
|
|
|
},
|
|
|
|
},
|
|
|
|
host: {
|
|
|
|
shared: {
|
|
|
|
enabled: 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
|
|
|
static_libs: [
|
|
|
|
"libbase",
|
2020-11-13 23:55:20 +00:00
|
|
|
"libcutils",
|
2020-11-16 23:08:18 +00:00
|
|
|
"liblog",
|
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
|
|
|
"libutils",
|
2020-11-16 23:08:18 +00:00
|
|
|
"libziparchive",
|
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
|
|
|
],
|
|
|
|
shared_libs: [
|
2017-09-27 16:20:31 -07:00
|
|
|
"libz",
|
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
|
|
|
],
|
2016-12-01 15:55:00 -08:00
|
|
|
},
|
2022-03-08 18:17:43 -08:00
|
|
|
host_linux: {
|
2020-11-02 16:16:17 +00:00
|
|
|
srcs: [
|
|
|
|
"CursorWindow.cpp",
|
|
|
|
],
|
|
|
|
},
|
2016-12-01 15:55:00 -08:00
|
|
|
windows: {
|
|
|
|
enabled: true,
|
|
|
|
},
|
|
|
|
},
|
2017-11-07 13:26:27 -08:00
|
|
|
sanitize: {
|
2020-07-28 14:38:20 -07:00
|
|
|
blocklist: "libandroidfw_blocklist.txt",
|
2017-11-07 13:26:27 -08:00
|
|
|
},
|
2016-12-01 15:55:00 -08:00
|
|
|
}
|
2017-10-11 16:50:37 -07:00
|
|
|
|
|
|
|
common_test_libs = [
|
|
|
|
"libandroidfw",
|
|
|
|
"libbase",
|
|
|
|
"libcutils",
|
|
|
|
"libutils",
|
|
|
|
"libziparchive",
|
|
|
|
]
|
|
|
|
|
|
|
|
cc_test {
|
|
|
|
name: "libandroidfw_tests",
|
|
|
|
host_supported: true,
|
|
|
|
defaults: ["libandroidfw_defaults"],
|
|
|
|
cppflags: [
|
|
|
|
// This is to suppress warnings/errors from gtest
|
|
|
|
"-Wno-unnamed-type-template-args",
|
|
|
|
],
|
|
|
|
srcs: [
|
|
|
|
// Helpers/infra for testing.
|
|
|
|
"tests/CommonHelpers.cpp",
|
|
|
|
"tests/TestHelpers.cpp",
|
|
|
|
"tests/TestMain.cpp",
|
|
|
|
|
|
|
|
// Actual tests.
|
|
|
|
"tests/ApkAssets_test.cpp",
|
|
|
|
"tests/AppAsLib_test.cpp",
|
|
|
|
"tests/Asset_test.cpp",
|
|
|
|
"tests/AssetManager2_test.cpp",
|
|
|
|
"tests/AttributeFinder_test.cpp",
|
|
|
|
"tests/AttributeResolution_test.cpp",
|
|
|
|
"tests/ByteBucketArray_test.cpp",
|
|
|
|
"tests/Config_test.cpp",
|
2018-06-20 08:46:41 +02:00
|
|
|
"tests/ConfigDescription_test.cpp",
|
2017-10-11 16:50:37 -07:00
|
|
|
"tests/ConfigLocale_test.cpp",
|
2018-08-22 11:22:54 -07:00
|
|
|
"tests/DynamicRefTable_test.cpp",
|
2017-10-11 16:50:37 -07:00
|
|
|
"tests/Idmap_test.cpp",
|
|
|
|
"tests/LoadedArsc_test.cpp",
|
2018-06-20 08:46:41 +02:00
|
|
|
"tests/Locale_test.cpp",
|
2017-10-11 16:50:37 -07:00
|
|
|
"tests/ResourceUtils_test.cpp",
|
|
|
|
"tests/ResTable_test.cpp",
|
|
|
|
"tests/Split_test.cpp",
|
|
|
|
"tests/StringPiece_test.cpp",
|
|
|
|
"tests/Theme_test.cpp",
|
|
|
|
"tests/TypeWrappers_test.cpp",
|
|
|
|
"tests/ZipUtils_test.cpp",
|
|
|
|
],
|
2018-02-12 14:27:46 -08:00
|
|
|
static_libs: ["libgmock"],
|
2017-10-11 16:50:37 -07:00
|
|
|
target: {
|
|
|
|
android: {
|
|
|
|
srcs: [
|
|
|
|
"tests/BackupData_test.cpp",
|
2020-09-26 18:57:32 -06:00
|
|
|
"tests/BackupHelpers_test.cpp",
|
|
|
|
"tests/CursorWindow_test.cpp",
|
2017-10-11 16:50:37 -07:00
|
|
|
"tests/ObbFile_test.cpp",
|
2018-09-27 13:32:30 +02:00
|
|
|
"tests/PosixUtils_test.cpp",
|
2017-10-11 16:50:37 -07:00
|
|
|
],
|
2020-11-04 08:59:06 -08:00
|
|
|
shared_libs: common_test_libs + [
|
|
|
|
"libbinder",
|
|
|
|
"liblog",
|
|
|
|
"libui",
|
|
|
|
],
|
2017-10-11 16:50:37 -07:00
|
|
|
},
|
|
|
|
host: {
|
2020-11-04 08:59:06 -08:00
|
|
|
static_libs: common_test_libs + [
|
|
|
|
"liblog",
|
|
|
|
"libz",
|
|
|
|
],
|
2017-10-11 16:50:37 -07:00
|
|
|
},
|
|
|
|
},
|
2019-08-16 10:20:39 -07:00
|
|
|
data: [
|
2019-07-01 09:48:23 -07:00
|
|
|
"tests/data/**/*.apk",
|
|
|
|
"tests/data/**/*.arsc",
|
|
|
|
"tests/data/**/*.idmap",
|
2019-08-16 10:20:39 -07:00
|
|
|
],
|
2018-12-18 16:06:40 -08:00
|
|
|
test_suites: ["device-tests"],
|
2017-10-11 16:50:37 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
cc_benchmark {
|
|
|
|
name: "libandroidfw_benchmarks",
|
|
|
|
defaults: ["libandroidfw_defaults"],
|
|
|
|
srcs: [
|
|
|
|
// Helpers/infra for benchmarking.
|
|
|
|
"tests/BenchMain.cpp",
|
|
|
|
"tests/BenchmarkHelpers.cpp",
|
|
|
|
"tests/CommonHelpers.cpp",
|
|
|
|
|
|
|
|
// Actual benchmarks.
|
|
|
|
"tests/AssetManager2_bench.cpp",
|
2018-02-12 14:27:46 -08:00
|
|
|
"tests/AttributeResolution_bench.cpp",
|
2020-09-26 18:57:32 -06:00
|
|
|
"tests/CursorWindow_bench.cpp",
|
2017-10-11 16:50:37 -07:00
|
|
|
"tests/SparseEntry_bench.cpp",
|
|
|
|
"tests/Theme_bench.cpp",
|
|
|
|
],
|
|
|
|
shared_libs: common_test_libs,
|
|
|
|
data: ["tests/data/**/*.apk"],
|
|
|
|
}
|
Add fuzzer for rewritten CursorWindow.
We recently rewrote CursorWindow, so let's get a fuzzer wired up
to see if it has any bugs.
This change creates a separate "libandroidfw_fuzz" library, since we
can't link to libbinder when building Windows host-side binaries;
the fuzzer doesn't need Window support.
And fix our first vulnerability where getFieldSlot() could be
tricked into reading out of bounds data.
The included corpus seed was generated using this example code:
CursorWindow* w = nullptr;
CursorWindow::create(android::String8("test"), 1 << 21, &w);
w->setNumColumns(3);
w->allocRow();
w->putLong(0,0,0xcafe);
w->putLong(0,1,0xcafe);
w->putLong(0,2,0xcafe);
// Row purposefully left empty
w->allocRow();
w->allocRow();
w->putNull(2,0);
w->putNull(2,1);
w->putNull(2,2);
w->allocRow();
w->putString(3,0,"cafe",5);
w->putString(3,1,"cafe",5);
w->putString(3,2,"cafe",5);
w->allocRow();
w->putDouble(4,0,3.14159f);
w->putDouble(4,1,3.14159f);
w->putDouble(4,2,3.14159f);
Parcel p;
w->writeToParcel(&p);
Bug: 169251528
Test: atest libandroidfw_tests:CursorWindowTest
Test: SANITIZE_HOST=address make ${FUZZER_NAME} && ${ANDROID_HOST_OUT}/fuzz/$(get_build_var HOST_ARCH)/${FUZZER_NAME}/${FUZZER_NAME}
Change-Id: I405d377900943de0ad732d3f1a1a0970e17d5140
2020-10-13 09:40:52 -06:00
|
|
|
|
|
|
|
cc_library {
|
|
|
|
name: "libandroidfw_fuzzer_lib",
|
|
|
|
defaults: ["libandroidfw_defaults"],
|
|
|
|
host_supported: true,
|
|
|
|
srcs: [
|
|
|
|
"CursorWindow.cpp",
|
|
|
|
],
|
|
|
|
export_include_dirs: ["include"],
|
|
|
|
target: {
|
|
|
|
android: {
|
2020-11-04 08:59:06 -08:00
|
|
|
shared_libs: common_test_libs + [
|
|
|
|
"libbinder",
|
|
|
|
"liblog",
|
|
|
|
],
|
Add fuzzer for rewritten CursorWindow.
We recently rewrote CursorWindow, so let's get a fuzzer wired up
to see if it has any bugs.
This change creates a separate "libandroidfw_fuzz" library, since we
can't link to libbinder when building Windows host-side binaries;
the fuzzer doesn't need Window support.
And fix our first vulnerability where getFieldSlot() could be
tricked into reading out of bounds data.
The included corpus seed was generated using this example code:
CursorWindow* w = nullptr;
CursorWindow::create(android::String8("test"), 1 << 21, &w);
w->setNumColumns(3);
w->allocRow();
w->putLong(0,0,0xcafe);
w->putLong(0,1,0xcafe);
w->putLong(0,2,0xcafe);
// Row purposefully left empty
w->allocRow();
w->allocRow();
w->putNull(2,0);
w->putNull(2,1);
w->putNull(2,2);
w->allocRow();
w->putString(3,0,"cafe",5);
w->putString(3,1,"cafe",5);
w->putString(3,2,"cafe",5);
w->allocRow();
w->putDouble(4,0,3.14159f);
w->putDouble(4,1,3.14159f);
w->putDouble(4,2,3.14159f);
Parcel p;
w->writeToParcel(&p);
Bug: 169251528
Test: atest libandroidfw_tests:CursorWindowTest
Test: SANITIZE_HOST=address make ${FUZZER_NAME} && ${ANDROID_HOST_OUT}/fuzz/$(get_build_var HOST_ARCH)/${FUZZER_NAME}/${FUZZER_NAME}
Change-Id: I405d377900943de0ad732d3f1a1a0970e17d5140
2020-10-13 09:40:52 -06:00
|
|
|
},
|
|
|
|
host: {
|
2020-11-04 08:59:06 -08:00
|
|
|
static_libs: common_test_libs + [
|
|
|
|
"libbinder",
|
|
|
|
"liblog",
|
|
|
|
],
|
|
|
|
},
|
|
|
|
darwin: {
|
|
|
|
// libbinder is not supported on mac
|
|
|
|
enabled: false,
|
Add fuzzer for rewritten CursorWindow.
We recently rewrote CursorWindow, so let's get a fuzzer wired up
to see if it has any bugs.
This change creates a separate "libandroidfw_fuzz" library, since we
can't link to libbinder when building Windows host-side binaries;
the fuzzer doesn't need Window support.
And fix our first vulnerability where getFieldSlot() could be
tricked into reading out of bounds data.
The included corpus seed was generated using this example code:
CursorWindow* w = nullptr;
CursorWindow::create(android::String8("test"), 1 << 21, &w);
w->setNumColumns(3);
w->allocRow();
w->putLong(0,0,0xcafe);
w->putLong(0,1,0xcafe);
w->putLong(0,2,0xcafe);
// Row purposefully left empty
w->allocRow();
w->allocRow();
w->putNull(2,0);
w->putNull(2,1);
w->putNull(2,2);
w->allocRow();
w->putString(3,0,"cafe",5);
w->putString(3,1,"cafe",5);
w->putString(3,2,"cafe",5);
w->allocRow();
w->putDouble(4,0,3.14159f);
w->putDouble(4,1,3.14159f);
w->putDouble(4,2,3.14159f);
Parcel p;
w->writeToParcel(&p);
Bug: 169251528
Test: atest libandroidfw_tests:CursorWindowTest
Test: SANITIZE_HOST=address make ${FUZZER_NAME} && ${ANDROID_HOST_OUT}/fuzz/$(get_build_var HOST_ARCH)/${FUZZER_NAME}/${FUZZER_NAME}
Change-Id: I405d377900943de0ad732d3f1a1a0970e17d5140
2020-10-13 09:40:52 -06:00
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|