This changes the default behavior of pom2bp to match pom2mk, and not
require pre-extraction of all of the manifests.
Test: convert an internal pom2mk user to pom2bp
Change-Id: I08120cce1f923ef28519563ffd772032b2e500ed
It was not printing out the flag descriptions because it was using the
default FlagSet instead of the custom FlagSet when calling
PrintDefaults.
Test: soong_zip --help
Change-Id: I8a5705f8701ce0c05dde144b9a14962faa384e65
There are no remaining users.
Also mark BUILD_BROKEN_ANDROIDMK_EXPORTS and BUILD_BROKEN_ENG_DEBUG_TAGS
as deprecated in scripts/build_broken_logs.go
Test: treehugger
Change-Id: If7892bef1b9001f12a99565f886b395cf1985e70
prebuilt_test is amended to ensure
f2976304f7 is not broken.
PathsForModuleSrc is called to check if the file is from correct module
(either from source or prebuilt module)
Bug: 130627486
Test: m
Change-Id: Ic5f467fbc2837727df92102530687e967cd5529f
Target SDK version is used for targeting an APEX to a specific set of
platform builds. Usually, the targeting is unrestricted (in case the
APEX can run on all platforms), or based on platform SDK version (e.g.
28 for P). However, when the platform is under development and SDK is
not finalized, the targeting should be much more fine-grained; the
APEX should be targeted to a very specific build that supports the same
set of APIs that the APEX was built against.
To support that, target sdk version is automatically set by the build
system. When the platform is released or SDK is finalized, the target sdk
version set to the SDK version number. If not, it is set to
<version_code>.<fingerprint> (e.g., Q.123456).
Note that the target sdk version set by the build system is used only
when the target sdk version is not explicitly set in
AndroidManifest.xml.
Bug: 130541924
Test: UNBUNDLED_BUILD_SDKS_FROM_SOURCE=true \
UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true \
TARGET_BUILD_APPS=com.android.tzdata m
build.ninja has --target_sdk_version Q.$$(cat out/soong/api_fingerprint.txt)
Test: aapt dump badging out/dist/com.android.tzdata.apex | grep \
targetSdkVersion shows:
targetSdkVersion:'Q.6ee443d9ad5f0cca7a43cfa97b7fc62a'
Change-Id: I086230d787f01075c28fc3f0163550300fa00212
PathsForModuleSrc does not work if a source module is replaced with a
prebuilt module. This is because the function uses GetDirectDepWithTag
with the name of the original source module. Since the dependency is
replaced and the prebuilt module has the name "prebuilt_<name>", the
search always fails.
Fixing this by re-implementing GetDirectDep* functions inside Soong
using VisitDirectDep.
Bug: 130627486
Test: m
Change-Id: I68d52668283c429d5e93c7f2c81f6a8db1f24893
Use codename.fingerprint format for targetSdkVersion if it is unset
in the manifest and UNBUNDLED_BUILD_TARGET_SDK_WITH_API_FINGERPRINT=true.
Test: manual
Bug: 130541924
Change-Id: I4e3b1274cc32038b00b292dc6d67559eb320e9e4
Move the rules to build framework.aidl into Soong, and use it
when compiling aidl files with sdk_version: "current".
Also fixes incorrectly using the aidl includes exported by the
"framework" module when the proguardRaiseDep dependency was
added.
Bug: 130798034
Test: sdk_test.go
Change-Id: I126adf1d9e7b6acb528875ff62b974ba7ad9a337
This will help avoid merge conflicts between branches that have
additional default libraries.
Test: sdk_test.go
Change-Id: I98d5b8b2ea939df7ef57686f3bd913d6a21edc5d
Merged-In: I98d5b8b2ea939df7ef57686f3bd913d6a21edc5d
Bug: 130787336
Test: m oemaids_header_gen oemaids_headers passwd group
Test: Set TARGET_FS_CONFIG_GEN to a list of paths
Change-Id: Ic1f7d38239f3f805ca0723c24005d3e18a811870
Some module types (`android_test`, etc.) set `optimize.enabled` by
default. If such module happens to have `defaults` attribute which
clears `optimize.enabled`, the latter value is ignored.
Fixes: 129858282
Test: unit tests in java_test.go,
`atest CtsExtendedMockingTestCases` succeeds with aog/936802
reverted (that is, with cts/test/mocking converted to Android.bp)
Change-Id: Ib8e3a0ab0bd489d70ed07f626082aeae31c45e7c
So that the output of build_test can be parsed to understand which
devices need changes.
Test: read out/soong.log
Change-Id: I40b25527ef72e3f646c0cfe62114b452fa3f27f6
Add java_sdk_library_import for use when a java_sdk_library may
be used by unbundled branches that do not have the project that
contains the original java_sdk_library module.
Bug: 130287656
Test: m checkbuild
Change-Id: I62df4bccc0da95ed6c8b31dab8f2c32cc3215e9e
llndk_* module types are not initialized via cc.Module.Init(). As a
consequence, mutated properties like HideFromMake, etc. were not
registered and this caused problem when the mutated properties are set
by one of the mutators like the sanitizerMutator. Specifically, both
asan and non-asan variant of an llndk_header were both exported to Make
although HideFromMake was set to true for the non-asan variant.
Fixing this bug by explicitly registering BaseProperties struct which
contains the mutated properties.
Bug: 130652996
Test: Following works:
$ lunch aosp_cf_x86_pasan-userdebug
$ mkdir frameworks/native/test && mkdir frameworks/native/test/include
$ cat > frameworks/native/test/Android.bp
llndk_headers {
name: "test_headers",
export_include_dirs: ["include"],
}
^D
$ SANITIZE_TARGET='address' make
Change-Id: I44e3668460448d79382617df61171b0ab5b4d98d
This reverts commit 61166dc047.
One difference from the earlier change is that import libraries are now
using the '.lib' extension instead of '.a' to prevent clash with
AdbWinApi.a.
Bug: http://b/110800681
The following flags that the binutils linkers support are not
available in lld for Windows:
-soname
--no-undefined
-rpath
Windows also uses "import libraries", which are stub libraries used only
for linking. The binutils linkers accepted a DLL and treated them as an
import library. But lld issues the following error:
lld-link: error: ...DLL: bad file type. Did you specify a DLL instead
of an import library?
To resolve this, pass '-out-implib=libFoo.lib' to lld when linking
libFoo.dll to get lld to generate an import library. Add libFoo.lib as
an implicit output to the 'ld' build rule.
Rewrite the shared libraries when building a library/binary to use the
import library instead of the DLL. As a side-effect, this also uses the
newly-created AdbWinApi.lib that's alongside
development/host/windows/prebuilt/usb/AdbWinApi.dll
Test: Run Windows tests (go/android-llvm-windows-testing) and check
absence of regressions. Also check that the following commands pass:
$ adb.exe devices
$ fastboot.exe devices
Change-Id: I34e07d345e0207086ac8e8ea12525d8c322b20fd
