PLATFORM_BASE_OS is used to set value for
ro.build.version.base_os which is used to qualify
a device build as SMR (Security Maintenance Release)
during APFE (Android Partner Approval) to optimize the test span.
See ag/26859560 on how we plan to use this variable.
Add PRODUCT_BASE_OS that can be used to override
PLATFORM_BASE_OS value before making it read_only.
Plan is to set the value for PRODUCT_BASE_OS using build flags.
This way, it can be easily set per device when making on-demand
SMR releases. In future, move it to be set via soong variable
during build process once build system side is ready.
Test: None
Bug: 155105803
Change-Id: I7c4a1f291bb426ad599e1dc937e6ecd3889b5820
This reverts commit 27f601f5d9.
Reason for revert: Droidmonitor triggered revert due to build breakage in b/348090986. Will be verifying through ABTD before submission.
Change-Id: I55e0880741e543309a7b991d49e59e4fa1f62e53
Many places in the codebase have checks like this:
if shipping level > X: do cool thing Y
This is great because it reduces the cost to upgrade and test
old Android devices or refactor their code. However, many
targets, such as the NDK, the SDK, mainline modules, and so on
do not set a shipping level, so they don't get to do the cool
thing Y.
In order to resolve this, we could modify every check to check
the default case. However, this is an invasive change, and it
is not maintainable. Instead, consider non-shipping products to
always be in the future.
In general, Android features are required to be backwards
compatible, so this should always work for things like mainline.
Also note, this means when someone adds a new feature Y like this,
they'll clearly see the impact of it being added everywhere, rather
than on such a small selection of newly shipping devices. This
avoids a risk where a change needs to be run on mainline modules (or
other targets) but is not tested in this configuration from the
start.
Future work: many `ifndef` checks can be cleaned up after this,
or if this approach makes sense, they can be cleaned up in this
CL.
Bug: 339026799
Bug: 279808973
Bug: 333908433
Test: builds of:
- errorprone-trunk_staging
- mainline_modules_sdks-trunk_staging-userdebug
- mainline_modules_x86_64-trunk_staging-userdebug
- ndk
- sdk-trunk_staging-userdebug
Test: too large number gives:
build/make/core/product_config.mk:598: error: integer greater than 10001 is not supported!.
Change-Id: I17c34267f774ea8b9265e1d798a67af7838715c5
This product config variables were previously used to prune Android.bp
files from soong analysis using blueprint_package_includes
Bug: 308188212
Test: m nothing
Change-Id: If3f88dbe2abb2db5f1112981e706d8a2cb228895
Having this in make has the following advantages
- allows this to be used in other places in make that are sensitive to
prebuilt selection, e.g. apex boot jars that are present in source but
not in prebuilt apexes
- collocates the various prebuilt special edge cases
Test: presubmits
Test: in internal, lunch cf_x86_64_phone-next-userdebug
Test: EMMA_INSTRUMENT_FRAMEWORK=true get_build_var PRODUCT_BUILD_IGNORE_APEX_CONTRIBUTION_CONTENTS
true
Bug: 308188056
Change-Id: I3e81b348e9f1e72e6d120a881d37356c413b005b
This reverts commit fa5bfb9d79.
Reason for revert: we were running into OTA failures b/333966507. The reason was that OTA compatibility tools on go/absign weren't updated with our v3 compatibility tools (which turns of v3 full OTA for devices launching prior to Android 15). Once we know that go/absign is updated, we can check in this change again
Change-Id: I789c24b57754d6ede794d7f9451ee0ca469c2fb4
(This relands aosp/3007754 with additional handling for go apexes. The
additional handling was added in internal in ag/26705862, so we need to
add this to aosp as well)
The ignore list is burdensome to maintain once we start adding the
module sdk contents to apex_contributions. Convert the variable to a
boolean. When set to true, all contents in `apex_contributions` will be
ignored
Test: m nothing on aosp,google and google_fullmte devices
Ignore-AOSP-first: CL topic does a cleanup of an internal only denylist
Merged-In: If899f6eaf5449c2aa789d0bd5b791a3db715c676
Merged-In: I4532f3743eb3b7121e1f5e522097c1aba3d9a4fd
Change-Id: I18db6657b78b2741c7f9af9e9d0150f85edeeda7
VSR_VENDOR_API_LEVEL is used to know the vendor API level for the VSR
requirement.
This must have the same value with the ro.vendor.api_level on run
time.
Bug: 332401254
Test: get_build_var VSR_VENDOR_API_LEVEL
Change-Id: I8e1fac8f05e4b06128738f377d63f26567d3902b
This revert was created by Android Culprit Assistant. The culprit was identified in the following culprit search session (http://go/aca-get/53721efb-c49e-4ce8-b96c-fd03598b4202).
Change-Id: Ifb82b8ec92b3ba8ad5da63ba497e4daad8093e4b
The ignore list is burdensome to maintain once we start adding the
module sdk contents to apex_contributions. Convert the variable to a
boolean. When set to true, all contents in `apex_contributions` will be
ignored
Bug: 308187268
Test: m nothing on aosp,google and google_fullmte devices
Ignore-AOSP-first: CL topic does a cleanup of an internal only denylist
Change-Id: If899f6eaf5449c2aa789d0bd5b791a3db715c676
Merged-In: If899f6eaf5449c2aa789d0bd5b791a3db715c676
(cherry picked from commit 025492c4ea092b7f25a4d442e67143954b5ffaa5)
On all api levels shipping higher than 34 (pixel 8), we want to enable
v3 cow version of the cow format
We need to make this change in product_config.mk since PRODUCT variables
have special interactions with inherit-product. PRODUCT_SHIPPING_API_LEVEL
is defined in device.mk and is unavailable to the parent makefile
(PRODUCT vars are cleared at the beginning of makefiles?).
Having the fallback vabc_cow_version in this file allows us to avoid the
hack below (we would have to modify each device.mk to add a temporary variable)
alternate solution:
We have to create a new variable SHIPPING_API_LEVEL that is a duplicate
of PRODUCT_SHIPPING_API_LEVEL. This is a hack to workaround the
inheritance flow (since vabc_features.mk -> android_t_baseline.mk ->
device.mk).This hack allows this variable to be seen by the parent
.mk file
Bug: 313962438
Test: u->v upgrade path for pixel 8. v->u dowgrade path for pixel 8
Change-Id: I6e1480e461c20a2fb07c5339828df0e6f6c0f9ec
If PRODUCT_CHECK_DEV_TYPE_VIOLATIONS is set or vendor api level is
greater than V (35), sepolicy dev type test will be run which checks if
all /dev nodes have dev_type attribute.
Bug: 303367345
Test: set PRODUCT_CHECK_DEV_TYPE_VIOLATIONS, see
sepolicy_dev_type_test's build command
Change-Id: Ibf25c1dacb5132ccda5265d6d2ce9fe655ffbc87
This is a new mechanism for asserting properties about your product
config. See the documentation in product_validation_checks.mk for
more information.
Test: Manually
Change-Id: I698dea899441f3773f839ea2ba1a2a6cfe59b57b
It has been mandatory since Android 11 (rvc) launching devices. Now we
can enable the product variants by default to all devices.
Bug: 300371698
Test: TH
Change-Id: I6b2d2e8e105ca35c38db8132486b1cb3bdbab40f
The newly added mainline_module_prebuilt_nightly and mainline_module_prebuilt_monthly_release are possible values for RELEASE_MAINLINE_MODULE_PREBUILT_VERSION (build flag in trunk stable). By adding these in BLUEPRINT_INCLUDE_TAGS_ALLOWLIST, we would be able to choose mainline modules prebuilts (apks) based on release config.
Bug: 294969202
Test: DEFAULT_MODULE_BUILD_FROM_SOURCE=false m (with 2 versions of apks, different blueprint_package_includes)
Change-Id: Ifcc49e5499d4659b73179fff715945cd2e3ca4fa
Rather than PRODUCT_SHIPPING_API_LEVEL, use board api level
(BOARD_API_LEVEL or BOARD_SHIPPING_API_LEVEL) to determine whether we
check coredomain violations or not.
Also provides a Makefile variable to override the flag, for targets that
want to turn on the check optionally.
Bug: 280547417
Test: see build command of vendor_seapp_contexts
Change-Id: I177630d33313334ca4a56a9be88b78cff678281e
...from devices launching after Android V.
Devices can add them back in explicitly now that they are also moved to
system_ext.
Test: m
Bug: 218588089
Change-Id: Ib3c917896c7a9b2c5940922c9faddb44cc7a0766
In the current setup in partner branch, we
1. Add blueprint_package_includes to prebuilts/module_sdk/*
2. Add the correct PRODUCT_INCLUDE_TAGS to partner_modules
This means in those setups,none of the prebuilts are visible to aosp products since
they they do not inherit partner_module makefiles.
```
e.g.
prebuilts/module_sdk/art/current/Android.bp
prebuilts/module_sdk/art/<go_specific>/current/Android.bp
// aosp_arm cannot find either
```
To solve this, this CL creates a default inclusion tag for all products
that do not set any PRODUCT_INCLUDE_TAGS explicitly.
In the previous example, Soong analysis of aosp_* will use
prebuilts/module_sdk/art/current/Android.bp. This should be a no-op for
aosp and internal branches since none of the Android.bp files today contains
blueprint_package_includes
Test: m nothing for aosp_arm in the test branch of b/278604467#comment20
Test: m nothing for partner product that uses big android sdk
Test: m nothing for partner product that uses go sdk
Bug: 278604467
Change-Id: I322b52c34ed339989207609dd0fd23c27ed1f697
Adds a new `$(call run-starlark,my/starlark/file.bzl)` function that
will run the starlark file and set all the variables in the
variables_to_export_to_make dictionary as make variables.
Fixes: 280685526
Test: m nothing repeatedly causes no ninja regeneration, but touching all_versions.bzl does. go test, ./out/rbcrun -mode=rbc ./build/make/tests/run.rbc
Change-Id: Ic72e18dd28dba8233ba2dfb658b5d03ccece1bfd
This replaces support for the unused
TARGET_PLATFORM_VERSION variable.
Now, if you pass three - separated
items the first is product, the
second is release and the third
is variant. If you only pass two
they're still product-variant
and the build system will choose
a reasonable default for release.
Test: run lunch with two and three items, confirmed values in the build banner
Change-Id: I128177d96ffe81b79b6945a24ebf37861c3b25fc
- rblf_cli and rblf_env
- -c and -f
This is in preparation for making rbcrun able to function as a more
general purpose starlark interpreter.
Bug: 280685526
Test: go test, ./out/rbc ./build/make/tests/run.rbc, ./build/bazel/ci/rbc_dashboard.py --quick aosp_arm64
Change-Id: Ifff9ce7b4369422f39c5003bb85a168c78bde7cf
The board configuration already had this inlined, and the addition
of a separate script makes it harder to follow what's happening.
Bug: 280685526
Test: ./build/bazel/ci/rbc_dashboard.py --quick aosp_arm64-userdebug
Change-Id: Ib76c4a46932ae81d84f854fbee5b0453266d6497
We have both with/without product interface enforced targets.
Because of this, unbundled apps in the product partition must consider
bundled cases and has to add `jni_uses_platform_apis: true` to use jni
libraries.
As targets with PRODUCT_SHIPPING_API_LEVEL > 29 must enforce the
product interfaces, if PRODUCT_SHIPPING_API_LEVEL is not defined,
enforce the product stable interface by default.
Bug: 273386586
Test: TH
Change-Id: I5874bf0ae8477fab7b1097ad24c9cc0d95543eb1
It just consisted of unused functions/variables, and had no edits
since the initial publish of android to git. It appears like it was
panned to have a device config similar to product config but was never
completed.
Test: Presubmits
Change-Id: I0ffcef1ae8bfd0611f1bede387f0c3e01fe53581
It turns out, in Cog workspaces, the order of files returned by "find"
command is inherently non-deterministic (they use an absl::HashMap which
intentionally tries to NOT guarantee sort order). This results in
varying order for the inner variable, which actually causes invalidation
and regeneration of the build graph (I'm guessing when "y" changes in
$(sort $(y)), it causes an invalidation in Make). Hence made the sort a
part of the inner command itself.
Tested: Ran the build with Cog and ensured graph wasn't regenerated
across reruns.
Bug: b/276397558
Change-Id: Ie772572048785793067f74c08ac3994ef6cbaa43
Example usage:
PRODUCT_INCLUDE_TAGS += use_myspecial_sdk
This also populates the allowlist with go/nogo mainline tags. Usage of
`PRODUCT_INCLUDE_TAGS` outside this allowlist will raise an error
in product config
Test: TH
Change-Id: Ica82a8f65cbfda600d72fc54fb873c1eaa1666a7
On devices launching after Android U, we no longer install the HIDL OMX
service. It is deprecated.
Test: Build and run Cuttlefish with SHIPING_API_LEVEL 33 and 34
Bug: 218588089
Change-Id: I9a6dbffd381bdad5428e9c365bd50445a9b14a67
Always enable the rbc board config along with
the product config now that board config works
well.
Bug: 231224938
Test: Presubmits
Change-Id: I52a79d53dfe54878477ee015bd21863c4cee6b05
