c61783b20d
The sdk snapshot must not be including implementation code for boot
libraries, the implementation is provided by dex jars within the
corresponding APEX. However, the snapshot does need a module for each
boot library so that the build can seamlessly access the dex files from
the APEX.
A java_library boot library (like core-oj) is represented in the
snapshot by a java_import module which requires a jar file to be
provided, otherwise it is disabled. However, that is provided purely
to keep Soong happy and should never be used.
Previously, the snapshot would contain an empty file for the jar. As
an empty file is an invalid jar any tool (like compiler) that tried
to consume it would fail which was the correct behavior. Unfortunately,
the error message that was produced was not very helpful, it was just
some variant on `invalid file` which lead to a lot of bugs being
raised.
This change replaces that empty file with a reference to the output
from a genrule which runs a script which produces a more useful error
message, with information on how to fix the issue, and fails the build.
It also adds a Name() method to the SdkMemberProperties type as that is
needed in AddInternalModule() to construct the name of the additional
module.
Tested as follows:
In AOSP/master make the following changes:
1. Temporarily set visibility on core-oj and core-libart to
//visibility:public.
2. Run packages/modules/common/build/mainline_modules_sdks.py to create
the snapshots.
For each of the S, T and latest snapshots I did the following in the
s-aml-prebuilt-test, t-aml-prebuilt-test and aosp/master branches:
1. Created an Android.bp file containing the following:
java_library {
name: "broken",
static_libs: [
"prebuilt_core-libart",
"prebuilt_core-oj",
],
}
2. Fix the visibility issues and run `m broken` where it fails with an
invalid file.
3. Delete the contents of the prebuilts/module_sdk/art/current/sdk
directory.
4. Unpack the relevant version of the art-module-sdk snapshot into the
directory.
5. Run `m broken` where it fails with the helpful message.
6. Test the instructions on how to use the ninja -t path tool to
identify the cause of the problem and fix it.
Bug: 257969510
Test: See above.
Change-Id: I125bde2d7202afff84c97daebcef37e21c548a3a
62 lines
2.7 KiB
Bash
Executable File
62 lines
2.7 KiB
Bash
Executable File
#!/bin/bash
|
|
|
|
# Copyright 2022 Google Inc. All rights reserved.
|
|
#
|
|
# 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.
|
|
|
|
# Script to detect and report an attempt to access an invalid implementation
|
|
# jar.
|
|
|
|
MOD=$1
|
|
|
|
cat <<EOF
|
|
|
|
$MOD is a java_library that generates a jar file which must not be accessed
|
|
from outside the mainline module that provides it. If you are seeing this
|
|
message it means that you are incorrectly attempting to use the jar file
|
|
from a java_import prebuilt of $MOD.
|
|
|
|
This is most likely due to an incorrect dependency on $MOD in an Android.mk
|
|
or Android.bp file. Please remove that dependency and replace with
|
|
something more appropriate, e.g. a dependency on an API provided by the
|
|
module.
|
|
|
|
If you do not know where the extraneous dependency was added then you can
|
|
run the following command to find a list of all the paths from the target
|
|
which you are trying to build to the target which produced this error.
|
|
|
|
prebuilts/build-tools/linux-x86/bin/ninja -f out/combined-\${TARGET_PRODUCT}.ninja -t path <target> <invalid-jar>
|
|
|
|
Where <target> is the build target you specified on the command line which
|
|
produces this error and <invalid-jar> is the rule that failed with this
|
|
message. If you are specifying multiple build targets then you will need to
|
|
run the above command for every target until you find the cause.
|
|
|
|
The command will output one (of the possibly many) dependency paths from
|
|
<target> to <invalid-jar>, one file/phony target per line. e.g. it may
|
|
output something like this:
|
|
|
|
....
|
|
out/soong/.intermediates/acme/broken/android_common/combined/broken.jar
|
|
out/soong/.intermediates/prebuilts/module_sdk/art/current/sdk/prebuilt_core-libart/android_common/combined/core-libart.jar
|
|
out/soong/.intermediates/prebuilts/module_sdk/art/current/sdk/art-module-sdk_core-libart-error/gen/this-file-will-never-be-created.jar
|
|
|
|
The last line is the failing target, the second to last line is a dependency
|
|
from the core-libart java_import onto the failing target, the third to last
|
|
line is the source of the dependency so you should look in acme/Android.bp
|
|
file for the "broken" module.
|
|
|
|
EOF
|
|
|
|
exit 1
|