Currently, target_sdk_version of MTS tests were being set to 10000 even
in release branches. This should only happen in active branches.
Test: Unit test
Test: aapt2 on CtsContentTestCases in udc-dev and verified
targetSdkVersion is 34
Bug: 279507428
Change-Id: Ib79318febc0f6e771b3679c0281a97357930ec56
ld -r reorders symbols and invalidates the .llvm_addrsig section, which
then causes warnings if the resulting object is used with ld --icf=safe.
The warning is especially common when building with musl, as the
clang_rt.crt* objects have .llvm_addrsig sections, are linked into
libc_musl_crt* using ld -r, and are then linked into every other binary
and shared library with --icf=safe.
Strip the .llvm_addrsig section after ld -r to prevent the warnings.
Test: m USE_HOST_MUSL=true host-native -k
Change-Id: Ia52a4756b9ebbb62115898d0de9f8641e6fea705
target_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid target_sdk_version in bp
files
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: I3c19245e29184bd9e5660ad8981966f64dfa9424
Currently it would return the default one even if the requested one is
an active sdk.
Bug: 270609292
Test: go test ./java
Test: built `rkpdapp` locally in internal and verified that its
targetSdkVersion is U and V
Test: TH
Change-Id: Idb03ff4786ff87fb7911bf31205941618a662404
Tests that run against mainline modules generally need to be built
twice: once for aosp (unsigned) and once for internal (signed).
The override_android_test rule is really useful for generating a
signed version of the unsigned test.
However, mainline tests need to use a MainlineTestModuleController
to only run tests on targets with the expected module. Since unsigned
and signed mainline modules have different package names, this means
the test config needs to be updated when overriding a test.
Add a new "mainline_package_name" argument so that android test rules
can update the targeted mainline package. Without this, the only way
to create a mainline package test is to instead use android_test, which
results in a lot of copy-pasta.
Test: added tests to soong
Test: manual, using a locally-modified RkpdAppUnitTest
Test: test_config_fixer_test.py
Change-Id: Idaffd63f225719a2bfda41018fda630b17db0080
Enforce target sdk version flag could only be used by `android_app`,
moving the check into a common function `generateAndroidBuildActions`.
This would ensure that the `enforce_target_sdk_version` flag
can also be set by `android_test` and `android_test_helper_app`.
Bug: b/227460469
Test: m nothing
Change-Id: I86e0bf684a5083221dae53907d9f548a0390b673
Add a test that verifies that that missing certificate path inserted
when AllowMissingDependencies is set uses a well formed extension
that won't trip up sign_target_files_apks.
Fixes: 259861670
Test: TestCertificates
Change-Id: I00656809698aed5f9d3aaadaecda9848d2882223
Due to GMS target SDK requirements (https://docs.partner.android.com/gms/policies/preview/mba#min-target-sdk)
we need to ensure all the mainline packages to target latest API
level. Currently, the team chases each module to bump their target
API level.
Updating the build code to make sure that mainline modules
(i.e updatable modules) target the latest sdk version by default.
It would be by default set to 10000 before SDK finalization and updated to the new API level after finalization.
Effectively it would mean:
1. '10000' in aosp and internal master
2. Finalized number in development branches like "33" in "tm-dev"
3. As sdk hasn't been finalised in "udc-dev", it would be "10000"
which would be automatically updated to finalized version after sdk finalization.
For local development if the target sdk version is required to be set,
users would need to set Updatable flag to false.
Enforce_default_target_sdk_version flag needs to be used in bp file,
if this feature needs to be tested locally when updatable: false.
Bug: b/227460469
Test: m nothing
Change-Id: I05e0ae74ae44fd73df75e91b926bcc924446253f
MTS tests built on unstable branches (e.g. git_master) should be testable on
old system images (e.g. S). However, they run into an error during installation
on older images:
`Requires development platform $<current_codename>, but this is a
release platform`
This CL fixes this issue by updating the target_sdk_version of MTS test apps
targeting current to the magical sdk_version 10000
Bug: 227473065
Test: go build ./java
Test: TH
Change-Id: Ic0358a48a19dc239defbb4ee8ec99225cce75584
JNI libs present in AAR files are ignored in the build. If those
libraries are necessary, they must be manually extracted and a
prebuilt_cc_library module must be created for them. Instead, we can
extract these libraries and copy them to an output APK as part of the build.
Bug: 228848794
Test: created android_app that depends on an android_library_import with
JNI embedded, and verified that .so libs are present in APK
Test: created android_app that depends on an android_library which
depends on android_library_import with JNI embedded, and verified
that .so libs are present in APK
Test: verified that multiple .so's from a single architecture are copied
to APK
Test: verified that the absence of a jni/<arch> folder or files in the
folder will cause the Ninja action to error
Change-Id: I242a862d7bd881f7a4a8c23493924d8fe441ea25
AndroidApp had its own HideFromMake method and flag that shadowed
the one in ModuleBase. This caused performOverrideMutator to set the
AndroidApp flag, but ModuleBase.skipInstall to read the ModuleBase
flag, resulting in a conflicting install rule being created. Remove
AndroidApp's HideFromMake in favor of the ModuleBase one.
Bug: 232788722
Test: TestOverrideAndroidAppWithPrebuilt
Change-Id: I8c0dfcb50ff4dc1e4d0574f150b10d79908f46aa
Move overrides attribute from appProperties to overridableAppProperties
Bug: 220029162
Test: m
Change-Id: I6f527df3173f142311734333ad37018c83d5e279
Merged-In: I6f527df3173f142311734333ad37018c83d5e279
(cherry picked from commit a2ce78f80d)
With aosp/1640364, all variants of a cc_* module use min_sdk_version as
the version part of the clang triple. Therefore, checking
min_sdk_version of jni_libs should be sufficient to ensure that there is
no unintended access to symbols in newer Android versions
Test: go test ./java
Test: TH
Bug: 155209650
Bug: 209409604
Change-Id: I6c064f8a6ea12c8aa40165a9063380306a180c9b
This reverts commit 0b1c70efbc.
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
Getting the first certificate will panic if there are no certificates,
which can happen when AllowMissingDependencies is set and the
certificate property is a module reference to a missing module.
Only get the first certificate if the list is not nil.
Bug: 228379411
Test: TestAppMissingCertificateAllowMissingDependencies
Change-Id: I046d75dbbd4f21f4a2b6851f558e430e9879fcff
Switch from generate-notice-files.py and mergenotice.py to htmlnotice.
Bug: 151177513
Bug: 213388645
Bug: 210912771
Test: m droid dist reportmissinglicenses
Change-Id: I6cac049d24f35ec358c6f341a04f4ba6161703bf
If the build file contains the apex_test module, add the
testOnly attribute to the application element of the
corresponding AndroidManifest file and set its value to true.
If the testOnly attribute is already present and has value
false, then do nothing.
Tests added in manifest_fixer_test.py to check if the updated
AndroidManifest file has the testOnly attribute set to true or not.
Bug: 213310150
Test: atest --host manifest_fixer_test
Test: m nothing
Test: manually checked the AndroidManifest file generated
Change-Id: I36247dbe0261c342d451a4422c314fd8fe0c2369
Previously, referencing a prebuilt android_app_import in an
android_test's instrumentation_for property instead of the source
android_app module (e.g. because the prebuilt is preferred) could
result in compilation errors if the android_test sources depended on
classes from the app. That is because while the android_app provides a
classes jar file to be added to the android_test's classpath the
android_app_import does not.
This change reports that situation as an error.
Bug: 207128192
Test: m nothing
Change-Id: I26ea90e7a3f57707fc0c094e0d8b8dc9a9e135ac
override_android_app can set "stem" property to set the APK name.
Bug: 193504286
Test: m (soong test)
Change-Id: I9ad66ea28bd1b030cb2c588d1f070d72e62ab1c7
When android_app.stem is set, use it as the APK name like other module
types.
Bug: 193504286
Test: m (soong test)
Change-Id: I4c95b77be382cff3cfecaf6ce38f99aed9f3238f
sdk
Previously in aosp/1907152, targetSdkVersion for all modules would be
10000 in release builds. This would cause sdk compatibility errors like
b/209301265#3 for modules that were targeting a released SDK
This CL adds an additional check to set targetSdkVersion to 10000 only
if a module's apilevel is in preview (i.e. unreleased SDK)
Bug: 209301265
Test: Built various apk combinations locally, and used aapt2 to check
targetSdkVersion
Test: TARGET_BUILD_APPS=xyz m CaptivePortalLoginTests #
targetSdkVersion: 30
Test: m CaptivePortalLoginTests #targetSdkVersion: 30
Test: (internal) TARGET_BUILD_APPS=xyz m MediaProviderGoogle #
targetSdkVersion: 10000
Test: (internal) m MediaProviderGoogle #targetSdkVersion: Tiramisu
Change-Id: Id2901f23d4e1b436f8906940e47edd606a93657d
The updated error message is more descriptive about the incompatibility
between platform_apis and sdk_version. Implemented as per the discussion
in b/204447559#17
Test: In build/soong, run go test ./java
Bug: 204447559
Change-Id: I826f0ce47313b337f1754a1b6bc11ce65c837a41
These are just out/ and out/soong/ and the old names were quite
confusing.
Test: Presubmits.
Merged-In: I999ca62162062f27e449f83ffb00fa580d4065b8
Merged-In: I2fcd80a9e376a6842a06aa104a9f6f5c5e16f8c7
Change-Id: Ib481d2aac40df8da1b74174dc8ec576c1cb48be0
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
Automatically add `uses_libs`/`optional_uses_libs` properties specified
in `java_library` modules to the apps that transitively depend on these
libraries.
Note that a library may choose to specify its <uses-library> deps as
either optional or required. If this is not the right choice for an app,
it should be able to override it by specifying its own `uses_libs`/
`optional_uses_libs` properties.
Add Soong tests to cover the new cases.
Bug: 196377222
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I601f3e2830ed9699b78d911966ee70812d32b4f6
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
Note that ART apex boot jars and core-icu4j are exceptions here as they
are not part of ApexBootJars. ART apex boot jars are defined in their
own variable, while core-icu4j is treated as a regular non-updatable
boot jar.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I3cea3d82ef521655a1a5ffa8cae2258ab9d08bfc
Deprecated the method to try and prevent any other uses being added.
Bug: 183650682
Test: m nothing
Change-Id: Ia6f43851e5a00c9d96af780e3bd21e03175e1a2f
This CL handles updatable boot jars in the same hacky way as we handle
non-updatable boot jars: it creates a set of predefined paths to the dex
jars in a global config, then traverses all modules in a singleton
context, finds updatable boot jars and adds copy rules from these jars
to the predefined paths. A proper way would be to register dependencies
of the dexpreopted modules on the boot jars and extracting paths to dex
files by walking these dependencies.
Bug: 178467404
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Test: added new Soong test
Change-Id: I87f764109315f79315d73bf43799b70eb010fc0b
Replaces uses of javaFixtureFactory with prepareForJavaTest and removes
the unused javaFixtureFactory.
Bug: 182885307
Test: m nothing
Change-Id: I809772d14af2af211b9e15ad676fbdc06b07cd46
Remove any uses, either direct (or indirect via testJavaConfig or
similar methods), of the package level buildDir variable from this
file.
Bug: 182885307
Test: m nothing
Change-Id: Ia8f835a8250934ef328cad02b272e6b94b13c459
This test relies on files provided by javaMockFS() so has been
converted to test fixtures to allow it to remove that dependency which
will allow javaMockFS() to be removed.
Bug: 182638834
Test: m nothing
Change-Id: I77b0205c91ff94b1c3c9ca00d4711451e3671571
Previously there were two different scripts that did similar things:
1) build/soong/scripts/manifest_check.py
2) build/make/core/verify_uses_libraries.sh
Both scripts extracted <uses-library> tags and `targetSdkVersion` from
the manifests of Java modules, but 1) worked for XML manifests, and 2)
worked for APKs. This CL reimplements the functionality from 2) in 1),
so that one script can handle both XML manifests and APKs.
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: Id1b66e4f3f30f307dba70cb111c7571762cb546a
Previously, testAppConfig added some extra files to the mock filesystem
before passing them to testConfig. However, those files are only needed
for TestApp so this converts TestApp to use test fixtures and populates
the mock filesystem with the extra files.
Without those extra files testApp and testAppConfig are equivalent to
testJava and testConfig respectively.
Bug: 181070625
Test: m nothing
Change-Id: I1d8a51223adde5b656948725bc4bc91040533625
They should have had `android:"path"` tags attached so that users can
point them to filegroup modules.
Test: app_test.go & app_import_test.go
Bug: 182175153
Change-Id: I5580408488ffe5fc12c869cbfb7a468713dcbc96
Some of the `uses_libs`/`optional_uses_libs` libraries may have a
library name that is different from the module name. In that case it is
necessary to patch these properties after `provides_uses_lib` for the
library is applied.
Bug: 132357300
Test: m nothing
Change-Id: I2e2248053787557f955a6b363c22e3bad0301ec7
Previously `provides_uses_lib` property affected only those
<uses-library> dependencies that are automatically deduced by Soong as
implicit Java SDK libraries reachable from the `libs` property. Other
<uses-library> dependencies that are explicitly added in `uses_libs` and
`optional_uses_libs` properties ignored `provides_uses_lib`.
As TestUsesLibraries shows (see the TODOs), Soong behaviour is still
incorrect in two ways (to be addressed in follow-up CLs):
- `uses_libs`/`optional_uses_libs` are passed to manifest_fixer
- verify_uses_libraries check is based on `uses_libs`/
`optional_uses_libs`, and not on the CLC as it should be
Bug: 132357300
Test: m nothing
Change-Id: I0ec7aab9dcd44554d1a79ddd382491c562266fa3
Use the java resources jar as the dex jar when building apps that
have no code.
Also remove maybeStrippedDexJar, the dex jar is never stripped now.
Fixes: 176305357
Test: TestAppJavaResources
Change-Id: Ic8b1165bd35d71237d307e7f5f895764e203a10d
Current test behaviour is incorrect, because libraries added via
`uses_libs`/`optional_uses_libs` ignore `provides_uses_lib` property.
The added TODO entries point at the incorrect behaviour, to be fixed in
the follow-up CLs.
Bug: 132357300
Test: m nothing
Change-Id: I35bfe227797aa37aa539e872052335677c798ee5
- Verify argument order for manifest_fixer args verify_uses_libraries.
- Rewrite manifest_fixer test so that it reveals arguments that should
not be there, add a TODO to remove them.
Bug: 132357300
Test: m nothing
Change-Id: I910e13b84f0464fc06b5b98395ddb45bf4120223
This fix a bug in a recent android_app_import-related change
(I8215aa1a6dad74b503eaa1169a64f8c30dda287c) where it uses an incorrect
module reference, and so disables a prebuilt module if its source-based
counterpart is disabled.
Test: app_test.go
Bug: 152343232
Change-Id: Ic7f5ca40be58f06e44b5ec4945caf209ef2dae96
This fixes a bug where android_app_import or android_test_import without
a matching variant or a default apk property value breaks the build.
Test: app_test.go
Fixes: 152343232
Change-Id: I8215aa1a6dad74b503eaa1169a64f8c30dda287c
If some Java library/app depends on an SDK component library (e.g. stubs
library), then it transitively depends on the SDK library itself
(because the component library has a dependency on its SDK library).
Previously having this transitive dependency resulted in adding the SDK
library to the <uses-library> dependencies of the library/app. However,
this doesn't make sense if the app has a *static* dependency on the
component library. This patch stops adding <uses-library> dependency in
that case.
Bug: 132357300
Test: m nothing
Test: added new Soong test that would previously fail with an error:
invalid build path for <uses-library> "fred"
Change-Id: I697a65e461037c95ec56b6c321afa4ec52ccbbec
Asked about error message including "against private API.Adjust
sdk_version", which is a bit hard to parse due to missing space. Also
tried to make error message less verbose, so that it is more clear what
to do, and fixed a grammar mistake.
Bug: N/A
Test: N/A
Change-Id: Ib9a30d86b5cb0e9b3b7d5576ecb9498a9b316042
Prepare for using Config when adding singletons by passing
Config to NewTestContext and NewContext instead of to ctx.Register.
This will enable a followup change to store SingletonMakeVarsProviders
registered on the Context in the Config, which is necessary to run
multiple tests in parallel without data races.
Test: all soong tests
Change-Id: Id229629a4e42ff4487d317241673837726c075fc
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
This dependency is incorrect and shouldn't exist.
It has been removed in https://r.android.com/1467918
Test: m nothing
Bug: 170710203
Bug: 132357300
Change-Id: If3036437e138b552436f135425e6bd15be043678
construct_context.py is a script that runs at Ninja stage and constructs
class loader context arguments for dex2oat. Previously it accepted lists
of library paths and concatenated them into one class loader context
string. The script also handled the dependency of "android.hidl.manager"
on "android.hidl.base" that is not tracked by the build system and must
be handled in a special way.
Now that class loader context representation is going to change from
flat lists to trees, passing paths to individual libraries as script
arguments is no longer possible, because a list of paths cannot
represent a class loader context tree. Passing the trees in a serialized
form is also inconvenient, because the script would have to parse them,
which would complicate it a lot.
Therefore this patch ports all the concatenation and "android.hidl.base"
handling to Soong. It is not possible to port the remaining script to
Soong because Soong has no information about the targetSdkVersiion of
the dexpreopted apps (it is in the manifest and sometimes in an APK, and
has to be extracted at Ninja time).
Test: construct_context_test.py
Test: new subtests in TestUsesLibs
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Icdb03cf00d1e27e4cff3844b89bfaec4de502dd7
Mimick the way PackageManager handles it at runtime: do add it to class
loader context for apps with targetSdkVersion < 30, but only if
"android.test.runner" is used. Previously it was not added at all.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I4c06635277ab13e21069b9fa0b46eb6a2547dfdd
Also, add tests for compatibility libraries in class loader context.
This CL separates special-case handling of compatibility libraries into
a "fixup" step that is done after class loader context is constructed by
Soong. This allows to handle compatibility libraries and normal
libraries uniformly, which should enable further simplification of class
loader context representation (in subsequent CLs).
Currently the only "fixup" step is removal of libraries from conditional
class loader context if they already are in unconditional context. This
check cannot be done at the time when the libraries are added to
conditional context, because the full uncoditional context is not yet
known at that time. Previously construction of unconditional context was
delayed, now it is no longer delayed and handled in the same way as
unconditional context, and the "fixup" does the filtering.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Ie71e9fb2d3d529b5317cd84e09ab3c853017c349
If an android_library has a proguard flag file, that
file should also be used when compiling apps with the
library.
Fixes: 171425221
Test: New unit test in app_test.go, and manually
With this change, users don't need to figure out which libraries
actually hold the resources to be overlaid when targetting apps with a
core lib dependency (e.g. Settings, SystemUI).
Fixes: 169898727
Test: app_test.go
Change-Id: I3c3b9dc0a377b1828db1199858a73d080a173205
This reverts commit 323dc60712.
Reason for revert: Possible cause of test instability
Bug: 170513220
Test: soong tests
Change-Id: Iee168e9fbb4210569e6cffcc23e60d111403abb8
* changes:
Fail the build if dexpreopt cannot find path to a <uses-library>.
Add dependency on implementation <uses-library> for modules that depend on component libraries.
Putting t.Parallel() in each test makes them run in parallel.
Additional t.Parallel() could be added to each subtest, although
that requires making a local copy of the loop variable for
table driven tests.
Test: m checkbuild
Change-Id: I5d9869ead441093f4d7c5757f2447385333a95a4
If a dexpreopted Java module depends on a component library (such as
stubs), it must be dexpreopted against the implementation library,
because that is what it will use at run time. Therefore dexpreopt needs
to know about the implementation library.
One of the subtests of TestUsesLibraries is removed. This is because the
subtest was previosuly split in two variants with the only difference
that the first variant had dependency on a stubs library, and the second
one had dependency on the implementation. The latter caused dexpreopt to
be disabled because Soong couldn't find the implementation (it had only
the name, but no access to the module). Now that there is a dependency
on the implementation, the problem goes away and the two subtest
variants can be merged into one.
Add a method for getting the name of the implementation library for the
optional SDK library. Currently it is the same as the SDK library name,
but it may change in future.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I584df4b6db874c7ae3c478231fc51572a46929b1
The test case I removed is invalid. The codename has had its int
assigned, but the config claims it is not final.
If this ever does need to be supported it's just a matter of making
sure the Q -> 29 mapping (or whatever) in the finalized codenames map
in android/api_levels.go.
Test: treehugger
Bug: http://b/154667674
Change-Id: I4f42ec2fd4a37750519ee3937938a1c65b6bb1e8
If BOARD_CURRENT_API_LEVEL_FOR_VENDOR_MODULES has a numeric value,
it replaces "current" or "system_current" with the version which
the flag indicates.
Bug: 163009188
Test: BOARD_CURRENT_API_LEVEL_FOR_VENDOR_MODULES=29 m, and then check if every vendor
java module's sdk_version is 29 if its sdk_version was current.
Change-Id: I17b49b8e02caf2d1bc57b91648d4420f3ad9fcb9
