aboutsummaryrefslogtreecommitdiff
path: root/dexpreopt/class_loader_context_test.go
Commit message (Collapse)AuthorAgeFilesLines
* Use per-app package list to avoid unnecessary dexpreopt.Jiakai Zhang2023-06-281-8/+16
| | | | | | | | | | | | | | | | Starting from aosp/2594905, dexpreopt depends on `$PRODUCT_OUT/product_packages.txt`. When PRODUCT_PACKAGES changes, dexpreopt has to rerun for all apps. This is not ideal. After this change, dexpreopt uses a per-app product_packages.txt that is filtered by the app's dependencies, and it uses `rsync --checksum` to prevent the file's mtime from being changed if the contents don't change. This avoids unnecessary dexpreopt reruns. Bug: 288218403 Test: m Test: Change PRODUCT_PACKAGES and see no dexpreopt reruns. Change-Id: I5788a9ee987dfd0abfd7d91cbcef748452290004
* Move CLC construction to Ninja phase.Jiakai Zhang2023-05-301-74/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, dexpreopt was often broken with optional libraries. This was because the CLC construction was done in Soong at an early stage, where we don't have sufficient information to determine whether an optional library is installed or not. For example, the "Settings" package uses an optional library called "androidx.window.extensions". On some devices, the library is installed, but on some other devices, it's not. Soong always adds the library to the CLC, meaning the CLC is wrong for devices which don't have the library. This change fixes the problem. See the tests below. After this change, the CLC construction is done by a Python script invoked at a very late stage. It uses product_packages.txt, which is generated by Make, to determine whether an optional library is installed or not, and filter out libraries that are not installed. Note that optional libraries are still added as dependencies by Soong. This is because dependencies have to be added at an early stage. This means what dex2oat eventually uses will be a subset of the dependencies, which is fine. Bug: 282877248 Test: m Test: atest construct_context_test Test: - 1. lunch aosp_cf_x86_64_phone-userdebug && m 2. Check the .invocation file of the "Settings" package (defined in .bp file) 3. See androidx.window.extensions Test: - 1. lunch aosp_redfin-userdebug && m 2. Check the .invocation file of the "Settings" package (defined in .bp file) 3. Don't see androidx.window.extensions Test: Check the .invocation file of the "Dialer" package (defined in .mk file) Test: - 1. Build a Pixel 5 system image and flash it to a Pixel 5 device. 2. adb shell pm art dump 3. See "reason=prebuilt" instead of "reason=vdex". (https://diff.googleplex.com/#key=fB6Ls9q2QGSN, before: left, after: right) Change-Id: Ia112bd7c2328373e68db6bffb74bf34030f683d8
* Revert "Don't add `uses_libs`/`optional_uses_libs` to the manifest_fixer."Ulya Trafimovich2022-05-041-51/+38
| | | | | | | | | | | | | | | | | | | | | | | This reverts commit 0b1c70efbcbb0c8408f44964923f5b156d025936. The reverted commit was based on the idea that uses-libraries that are explicitly specified in build files should not be implicitly added to the manifest, as that would mean that anything added to the build files will flow to the manifest. Although this logic is correct, it prevents propagation of uses-libraries from dependencies, which is wrong: if a library has an explicit uses-library property in Android.bp, this property is expected to be propagated to the library's dependencies. Failing to do so would mean that every user of that library has to add uses-library property to their build files, which doesn't scale (see b/214255490 for example). Bug: 214255490 Test: lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd \ && adb wait-for-device && adb root \ && adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch' # empty output, no errors at boot Change-Id: I6f420e76a89aa2f37be99f877711736640f2c361
* Correctly serialize class loader context for "any" SDK version to JSON.Ulya Trafimovich2022-04-281-0/+32
| | | | | | | | | | | | | Previously "any" was serialized as its numeric value, 10000. But other code in makefiles and scripts expects string "any", and dexpreopt.config files generated by Make (for Android.mk modules) have "any" not 10000. Bug: 214255490 Test: lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd \ && adb wait-for-device && adb root \ && adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch' # empty output, no errors at boot Change-Id: Id5e80eb8a90d9786b5cb999c172aaecb44952f76
* Add support for excluding libraries from class loader contextsPaul Duffin2022-02-071-0/+105
| | | | | | | | | | | | | | | | A number of tests in the cts/tests/signature/api-check check for the accessibility of classes from the android.test.base, android.test.runner and android.test.mock libraries. Some tests expect to find the classes other do not. Unfortunately, the tests use libraries, specifically compatibility-device-util-axt, that depend on the android.test... libraries which causes Soong to implicitly add <uses-library> entries to the manifest so that they will be accessible at runtime. That causes the tests that do not expect to find the classes to fail. Bug: 209607558 Test: m nothing Change-Id: I54c194ab23d5a70df790ece3fe98f2b3d6a1c1f6
* Fix OutDir vs SoongOutDir in testsColin Cross2021-11-091-15/+15
| | | | | | | | Tests were using the same value for OutDir and SoongOutDir, separate them to allow a test that needs to distinguish between them. Test: all soong tests Change-Id: Ibd78758c133a7f07bead3f51b699052676f92fbd
* Don't add `uses_libs`/`optional_uses_libs` to the manifest_fixer.Ulya Trafimovich2021-08-201-28/+33
| | | | | | | | | | | | | | | | These properties specify libraries that cannot be implicitly inferred by Soong. If these properties are added to Android.bp, this can only be for the reason that there is a <uses-library> tag in the manifest which is unknown to the build system. Adding them to the manifest_fixer doesn't make sense: if they are not in the manifest, they should be removed from Android.bp as well. Bug: 132357300 Test: $ lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd $ adb wait-for-device && adb root && adb logcat \ | grep -E 'ClassLoaderContext [a-z ]+ mismatch' # empty grep output, no errors Change-Id: Ic6eb5268a954ef3be7f06a181ec72af99000c547
* Fix the way manifest fixer detects optional <uses-library> entries.Ulya Trafimovich2021-08-131-37/+51
| | | | | | | | | | | | | | | | | | | Previously manifest_fixer used a naive way to distiniguish optional libs from required ones: it checked if a library is on the list of optional compatibility libraries. This works for compatibility libs, but not for other libs. Now we properly track optionality through all stages of the build, starting with the addition of the library as a dependency (here's where the `uses_libs`/`optional_uses_libs` distinction kicks in), store it in dependency tag and propagate to class loader context, and from there to the manifest_fixer. The tests have been updated accordingly. Bug: 196377222 Test: lunch bertha_x86_64-userdebug && m droid dist cts mts Change-Id: I3631ce59ebe47116ce7a9b3d33a86f636846ef0f
* Fix toJsonClassLoaderContextRec size bugJeongik Cha2021-04-221-0/+23
| | | | | | | | | toJsonClassLoaderContextRec's size is twice as large than expected. And the initial values is filled with null value. Bug: 158843648 Test: m nothing(testcase is added) Change-Id: I24c23269bd16baa18481f34b85c543d41f26d0e0
* Remove obsolete class loader context API and update unit tests.Ulya Trafimovich2021-01-051-53/+44
| | | | | | | | | | | | | | The removed API has been unused since https://r.android.com/1533342 (except for unit tests). Changes in the unit tests reflect the change of API in https://r.android.com/1533342: early errors caused by unknown library paths at CLC construction time have been replaced with late errors at the time of CLC validation. Bug: 132357300 Test: m nothing Change-Id: I739c7c41b6f882b7e28cdd6acd05961d754d8687
* Fix library order in class loader context to agree with PackageManager.Ulya Trafimovich2020-12-231-0/+42
| | | | | | | | | | | | | | | | PackageManager adds compatibility libraries for different SDK versions in descending order, and Soong should do the same. Bug: 132357300 Test: lunch aosp_cf_x86_phone-userdebug && m \ && launch_cvd \ && adb wait-for-device \ && adb logcat | grep -E 'ClassLoaderContext [a-z ]+ mismatch' [no messages "ClassLoaderContext classpath element mismatch"] Change-Id: Ib1d981808ae4022b2c6e73f407a003e8b8e9c7d6
* Make error message more precise.Ulya Trafimovich2020-12-021-1/+1
| | | | | | Bug: 132357300 Test: m nothing Change-Id: Iaac6aaf61a3bbf8476f0b11cf2c01d7d96a79920
* Assume any <uses-library> is shared, add only toplevel ones to manifest.Ulya Trafimovich2020-11-251-28/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reworks the approach introduced in https://r.android.com/1450819. That patch based the decision which libraries should be added to the manifest <uses-library> tags by the manifest_fixer on the "shared" status of the library. That approach is incorrect for two reasons: - It doesn't make sense to have a non-shared library in class loader context ("shared" libraries are those specified in frameworks/base/data/etc/platform.xml, and they are the only ones that PackageManager knows about). - It doesn't make sense to add anything but the top-level of the class loader context tree to the manifest, because this part of the tree is flattened to a sequence, and PackageManager cannot restore it to the previous tree shape (there is an information loss). This patch removes the "shared" bit of information from class loader context elements and assumes that all libraries that end up in class loader context are shared. Consequently, only the top-level libraries should be passed to manifest_fixer. Test: lunch aosp_cf_x86_phone-userdebug && m Bug: 132357300 Bug: 168686456 Change-Id: I902690f0f38f1047fa79cf6ccbe956077eceaab0
* Do not add dependencies of shared SDK libraries to manifest_fixer.Ulya Trafimovich2020-11-161-23/+28
| | | | | | | Test: lunch aosp_cf_x86_phone-userdebug && m Bug: 132357300 Bug: 168686456 Change-Id: Ibd9742684fa6a8f1353ca0e513f7fa814a6ec9fc
* Add nested class loader subcontext at the proper hierarchy level.Ulya Trafimovich2020-11-161-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding a subcontext in a class loader context tree, there are two possible cases: 1) the root of the subcontext is itself a <uses-library> and should be present as a node in the tree, or 2) the root is not a <uses-library>, but some of its dependencies are -- in that case they should be disconnected from the root, and the resulting forrest should be added at the top-level. Example: 1) C is a <uses-library>: A ├── B └── C ├── D └── E └── F 2) C is not a <uses-library>: A ├── B ├── D └── E └── F Before the patch subcontexts for transitive dependencies were added before the subcontext for the direct dependency (even if it was a <uses-library>, resulting in case-2 hierarchy when case-1 should have been used. Previosuly this didn't matter because class loader context was a flat set of libraries, but now it matters because class loader context is a tree. This patch changes the order in which libraries are added, so that direct dependencies are added before transitive ones. The context adding method now accepts an "implicit root" parameter, so that when adding transitive dependencies it can check if the corresponding direct dependency is a <uses-library> and already present in the context. Partially constructed class loader context is now propagated top-down into aapt.buildActions, so that the method can use existing part of the context to decide where the missing part should be connected. Test: lunch aosp_cf_x86_phone-userdebug && m Bug: 132357300 Change-Id: I649aff9e27494306885a4f4fc90226c399636b57
* Disallow adding nested conditional class loader context.Ulya Trafimovich2020-11-161-0/+10
| | | | | | | | | | | | Nested conditional context doesn't make sense because conditional context is only needed for compatibility libraries, and those are only used by apps, and apps are always at the root of class loader context tree. Therefore, trying to add conditional nested context can only mean an error somewhere on the way. Test: lunch aosp_cf_x86_phone-userdebug && m Bug: 132357300 Change-Id: Iadeaaf89fdb11cb23b107c6fb074b1bc765256be
* Rework class loader context implementation.Ulya Trafimovich2020-11-031-71/+62
| | | | | | | | | | | | | | | | | | | | | | | | | The old representation consisted of a list of libraries (UsesLibraries), a list of optional libraries (OptionalUsesLibraries) and a mapping from library name to its build/install paths (LibraryPaths). The separation into lists and map was necessary because of special handling of compatibility libraries, which is now unified with normal libraries. The new representation is a mapping from target SDK version to a tree structure ClassLoaderContext. Each node of the tree represents a library and contains library name, build/install paths and a slice of subcontexts for dependencies. The same library may occur in the tree multiple times in case it is a dependency of multiple libraries. The order in which libraries are added matters (the resulting tree shape may be different). Test results have to be updated, as the resulting <uses-library> list is reodered (previously it was a sorted list of map keys, and now it is formed by a depth-first preorder traversal of the class loader tree). Test: lunch aosp_cf_x86_phone-userdebug && m Bug: 132357300 Bug: 168686456 Change-Id: I11be8cd2967f004fd58753d7c5fb99fed179cd63
* Add unit tests for class loader context.Ulya Trafimovich2020-10-291-0/+225
Test: lunch aosp_cf_x86_phone-userdebug && m Bug: 132357300 Change-Id: I96a1e6cef86652e429b1678a655fc0b02f40d00c