|
1 | 1 | # Build System Changes for Android.mk Writers
|
2 | 2 |
|
| 3 | +## Dexpreopt starts enforcing `<uses-library>` checks (for Java modules) |
| 4 | + |
| 5 | +In order to construct correct class loader context for dexpreopt, build system |
| 6 | +needs to know about the shared library dependencies of Java modules listed in |
| 7 | +the `<uses-library>` tags in the manifest. Since the build system does not have |
| 8 | +access to the manifest contents, that information must be present in the build |
| 9 | +files. In simple cases Soong is able to infer it from its knowledge of Java SDK |
| 10 | +libraries and the `libs` property in Android.bp, but in more complex cases it is |
| 11 | +necessary to add the missing information in Android.bp/Android.mk manually. |
| 12 | + |
| 13 | +To specify a list of libraries for a given modules, use: |
| 14 | + |
| 15 | +* Android.bp properties: `uses_libs`, `optional_uses_libs` |
| 16 | +* Android.mk variables: `LOCAL_USES_LIBRARIES`, `LOCAL_OPTIONAL_USES_LIBRARIES` |
| 17 | + |
| 18 | +If a library is in `libs`, it usually should *not* be added to the above |
| 19 | +properties, and Soong should be able to infer the `<uses-library>` tag. But |
| 20 | +sometimes a library also needs additional information in its |
| 21 | +Android.bp/Android.mk file (e.g. when it is a `java_library` rather than a |
| 22 | +`java_sdk_library`, or when the library name is different from its module name, |
| 23 | +or when the module is defined in Android.mk rather than Android.bp). In such |
| 24 | +cases it is possible to tell the build system that the library provides a |
| 25 | +`<uses-library>` with a given name (however, this is discouraged and will be |
| 26 | +deprecated in the future, and it is recommended to fix the underlying problem): |
| 27 | + |
| 28 | +* Android.bp property: `provides_uses_lib` |
| 29 | +* Android.mk variable: `LOCAL_PROVIDES_USES_LIBRARY` |
| 30 | + |
| 31 | +It is possible to disable the check on a per-module basis. When doing that it is |
| 32 | +also recommended to disable dexpreopt, as disabling a failed check will result |
| 33 | +in incorrect class loader context recorded in the .odex file, which will cause |
| 34 | +class loader context mismatch and dexopt at first boot. |
| 35 | + |
| 36 | +* Android.bp property: `enforce_uses_lib` |
| 37 | +* Android.mk variable: `LOCAL_ENFORCE_USES_LIBRARIES` |
| 38 | + |
| 39 | +Finally, it is possible to globally disable the check: |
| 40 | + |
| 41 | +* For a given product: `PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true` |
| 42 | +* On the command line: `RELAX_USES_LIBRARY_CHECK=true` |
| 43 | + |
| 44 | +The environment variable overrides the product variable, so it is possible to |
| 45 | +disable the check for a product, but quickly re-enable it for a local build. |
| 46 | + |
3 | 47 | ## `LOCAL_REQUIRED_MODULES` requires listed modules to exist {#BUILD_BROKEN_MISSING_REQUIRED_MODULES}
|
4 | 48 |
|
5 | 49 | Modules listed in `LOCAL_REQUIRED_MODULES`, `LOCAL_HOST_REQUIRED_MODULES` and
|
|
0 commit comments