Invokes hiddenAPIExtractInformation() on the dex jar provided by the
deapexer (on behalf of prebuilt_apex) so that hiddenAPI can extract the
information it needs, if anything, from the dex file (and accompanying
classes implementation file).
The dex file provided by deapexer has already had the hiddenapi
information encoded into it so it does not need to do that again.
This change adds the primary parameter to hiddenAPIExtractInformation()
and checks it (and also the hiddenAPI.active property) before it does
anything. That ensures that it behaves correctly when called directly
as well as when called from hiddenAPIExtractAndEncode().
Bug: 178361284
Test: m droid
Verified that hiddenapi files (both aggregated ones and for the
individual modules) are not affected by this change.
Also verified that the hiddenapi files created when using the
prebuilts (using SOONG_CONFIG_art_module_source_build=false) are
the same as when using the source. There is a slight difference
in the order but otherwise identical.
Change-Id: I7abb63fd310bb94787ab7f4821e5fd283dc03046
A follow up change needs to be able to contribute to the information
the hiddenapi process collates without having a dex file encoded. This
change pushes all the functionality related to information gathering
into the hiddenAPIGenerateCSV() method and then renames it and the
hiddenAPI() method to make it clearer what they do.
Bug: 178361284
Test: m droid
Verified that hiddenapi files (both aggregated ones and for the
individual modules) are not affected by this change.
Change-Id: I04417720216a0fbadcd88e6185e7de6570af6216
Previously, the hiddenapi() method combined both checks to determine
whether a module contributed to/was modified by the hiddenapi process
and logic to create ninja rules to perform those tasks. This change
separates the former out into a new initHiddenAPI() method.
The main purpose of this is to simplify the process of allowing the
CSV generation to be separated from the encoding. That is required
because when a java_import retrieves its dex file from the apex it
has already been encoded.
The initHiddenAPI() method is only called for java.Library (and
indirectly for java.SdkLibrary) and java.Import modules which means
that the hiddenapi() method does nothing for any other module type.
That is consistent with the previous behaviour because while the
hiddenapi() method is called for other module types they fail because
the boot image jars only support java_library, java_sdk_library,
and java_import at the moment. While it will need to support
java_sdk_library_import once any of the libraries that are currently
provided as java_sdk_library modules switches to providing prebuilts
that is outside the scope of this work.
Bug: 178361284
Test: m droid
Verified that hiddenapi files (both aggregated ones and for the
individual modules) are not affected by this change.
Change-Id: Iaa91e0a8e2bffec03296dd894e9662556f4464c0
Jarjar doesn't exit with a nonzero return code when there is a syntax
error in a rules file and doesn't write the output file. Without a
nonzero return code ninja prints a warning but continues, which leads
to stale results on incremental builds where the output file already
exists, or delayed errors on clean builds whre the output file didn't
exist.
Delete the output file before running jarjar, and then check if it
exists after running jarjar.
Fixes: 119516143
Test: m out/target/common/obj/APPS/TeleService_intermediates/classes.jar
Change-Id: I7e9f7ff34de565a986ab0dc6e375f606c91c3846
Prevents the hiddenapi files index and metadata files from including
duplicate entries.
Bug: 178361284
Test: m droid
Compared hiddenapi files before and after change
Verified that the only differences were due to the removal of duplicates
Used sort -u to remove duplicates from before file and compared with after file
Change-Id: I0b9e420aec42cdcf4584099a7ffd2ed9c3715d6d
The index file and the metadata file both currently include duplicate
entries due to them including both the <x> and <x>.impl libraries
created by java_sdk_library in their inputs, plus including both source
and prebuilt versions of the same named module. This change adds a test
to illustrate that behavior. A follow up change will correct the problem
and update the test accordingly.
This change only adds a test for the index file because the metadata
file depends on files from frameworks/base which makes it difficult to
test. Bug 177317659 will fix that and allow the metadata file
generation to be tested too.
Bug: 178361284
Test: m nothing
Change-Id: I33921d7267c9f4bb42726343d73f8a396d536aaa
By enabling an android_app_import module to supply the
special framework-res module, it becomes possible to
create a split build that excludes the source of over
10,000 files under frameworks/base/core/res, replacing
this source with a prebuilt. However, since other parts
of a monolithic build use the source of framework-res,
this scheme works only if your split build manifest
excludes modules that depend on framework-res source.
Bug: 176851898
Test: lunch aosp_arm64-userdebug && m nothing
Test: new TestAndroidAppImportExportPackageResources
Test: local build without prebuilt framework-res
Test: local build with prebuilt framework-res
Change-Id: If00d9dbc656c8406c038448d09f93f767c1e06d1
Hiddenapi processing currently requires access to the class
implementation jars for libraries on the bootclasspath which means that
they need to be provided as part of the prebuilts. This change modifies
the java_boot_libs property on the sdk to make those files available.
Modularization of the hiddenapi processing will hopefully remove the
need for these to be exported so this should be temporary.
Bug: 178361284
Test: m art-module-sdk
check generated snapshot zip contains implementation jars
Change-Id: I9e94662dddb0ddb85a477ae6d27e533085147e88
Previously, it ignored any module that was not a platform apex variant
however that required every module that was referenced from the boot
jars to have a platform variant which is not the case when building
from prebuilts.
This change switches it to explicitly check that the variant is for
either the appropriate apex or the platform depending on what is
configured in the BootJars or UpdatableBootJars.
It partially duplicates some logic from the getBootImageJar() function.
It intentionally does not refactor the getBootImageJar() to allow for
reuse because coupling the hiddenapi and dexpreopt logic would make
refactoring either of them more difficult. Any duplicated code will be
deduped once they have both been refactored.
Bug: 178361284
Test: m droid
Change-Id: I4b4e0dc8ee40c1ba1713d7ef72df13d175e84af6
This currently expands all globs, still need to support converting glob
syntax.
Test: go build_conversion_test
Test: GENERATE_BAZEL_FILES=true m nothing
Test: m nothing
Bug: 165114590
Change-Id: If7b26e8e663d17566fad9614ca87a8da1f095284
This allows java_test_host to have arch-specific data files. Currently,
VirtualizationHostTestCases needs this to have arch-specific kernels as
its data.
Bug: N/A
Test: m VirtualizationHostTestCases
Change-Id: Ib5680ef48b613955ad92c9bc212184ac75900d3e
A path to an nonexistent file caused dex2oat to write an empty path in
the class loader context stored inside of the OAT/ODEX file, which
resulted in class loader context mistmatch and a failure to load
dexpreopt code on device.
An example of a faulty class loader context for GoogleDialer, can be
seen either with oatdump or by grepping logcat for class loader context
mimatch messages (the first empty PCL[] is expected, note the second
empty PCL[] in the subcontext for shared libraries):
PCL[]{PCL[]#PCL[/system/framework/org.apache.http.legacy.jar*22205474]
This CL removes the nonexistent path from the generated dexpreopt.config
file, which works in conjunction with a change in makefiles that stops
using the removed config field. This is possible because makefiles can
access DEX files using a module name and "intermediates-dir-for" macro.
Bug: 132357300
Test: lunch 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: I8d16f77c6f76ad6234cc4114ad3545cbe572ef13
Previously, ConfiguredJarList would accept an empty apex name,
e.g. ":jar" which makes no sense as every apex has to have a non-empty
name. This change makes an empty apex invalid.
In order to improve the test coverage of the TestConfiguredJarList test
this change also changes the implementation of
CreateTestConfiguredJarList([]string) to marshal the supplied strings
into a json list and then unmarshal into a ConfiguredJarList which more
closely matches how it is used at runtime.
Bug: 178361284
Test: m nothing
Change-Id: I7dfec6b4cc1923aa99746e976da0393922ef0791
