Apprently target-specific variables are only valid for the body of
the target, not its dependency list, so the dependency on the zip file
wasn't being added.
Bug: 340392832
Test: m, rm file_list.txt and the zip file, m again, and ensure we don't get an error that the zip file doesn't exist
Change-Id: Idaca6606ff24055aa98c78ca1206b587cc1df4d2
This reverts commit d17ef4a30b.
Reason for revert: build breakage on sdk_goog3_x86_64-trunk_staging-userdebug
Change-Id: I884df8b07afbbcdc1e07930163108f0baa503014
This reverts commit 1cbd8211e7.
Reason for revert: Droidmonitor triggered revert due to breakage in b/341118115
Change-Id: I0fed4225bd1d4d8888334fdc2a9fac353b748edd
This reverts commit 3f0eba2bdc.
Reason for revert: Causes build flag changes to be ignored sometimes. Better fix is in progress.
Merged-In: Ic85be1da3765656cef8da4ec03d0b1ca7d5d625e
Change-Id: I2c06770b2ff86c69a5de89962ab9bf48bedfe6fe
With our version compatibility check, overriding our cow version no
longer works. Updating this check to only apply if a command line
vabc_cow_version is not specified.
NOTE: the ota may not successfully apply, depending on device if we
override the cow version
Test: th
Change-Id: Ibbed6cf94cc2e91597d0c249dc8ade314b8341a2
Low memory devices place special emphasis on memory constraints and cpu
utilization. We want to expose a set of build configurations that allow
these devices to fine tune resource usage during OTA installation.
Our strategy will be the following.
1. For any tunable needed in first stage init, read the .ro prop during
ota installation, propogate the configuration to SnapshotUpdateStatus
proto, then read the property from /metadata upon first reboot (since
.ro properties are not available here)
2. For tunables which aren't needed until second stage init, read the
.ro prop directly.
This first CL will just add the build configurations to the build
system. Subsequent CL's will forward the configs to protobufs and
snapuserd daemon
Bug: 332255580
Test: th
Change-Id: I31b36b42f8fba997c772fe1a4ba99b17128b3eca
I changed the installs file to be after Android.mk files in
aosp/3080639, in order to minimize the information given to Android.mk
files. But it appears that some exotic vendor builds actually rely
on this information (when they shouldn't).
Bug: 340254841
Test: diff'd out/target/product/<vendor>/installed-files-vendor.txt before/after this cl, and with a revert of aosp/3080639
Change-Id: I00a06fe984397e4dba57352850f5e2484d17f657
Framework already has nano protos, and reusing them won't
introduce extra dependencies for the apps
This is setting up the resources flagging in the framework
Bug: 297373084
Test: Built with related changes
Change-Id: I518bd56f56c42e0adef0002e95f8948e0904fb43
It's very simple logic, and running get_build_var to do it is slow
and has side effects (like needing a lunch target, creating an out
directory, etc.)
Test: source envsetup.sh
Change-Id: If260efd21713874fba7c15dbc0fd23442d776f8a
Merged-In: If260efd21713874fba7c15dbc0fd23442d776f8a
aconfig_device_paths uses `include_str!` to include a text file
containing comma-separated strings with each partition aconfig file.
The lib does not handle the escaped newlines and quotation marks.
Adds proper handling.
Test: cargo t && m -j120 && acloud create --local-image && adb shell aflags list
Bug: 340514768
Change-Id: I75214bf02dd962d8291f1654ade8cbce1cda9fde
The lib is a part of the adbd apex and isn't used from outside of the
apex. Remove the lib from /system/lib[64].
Bug: N/A
Test: watch TH
Change-Id: I2c95fa72befa5a660a4f97d9f26459066b40c1e2
Sometimes android_app_bundles exist in the tree but are not added
to PRODUCT_PACKAGES, in that case, they shouldn't be added to
file_list.txt.
We can tell if they're in PRODUCT_PACKAGES by if their primary file
is present in the list of files to install.
Bug: 337869220
Test: m out/target/product/emu64x/obj/PACKAGING/system_intermediates/file_list.txt and checking it for the extra NetworkStackGoogle apks, with a local NetworkStackGoogle android_app_set added into the tree
Change-Id: I22bcd9e972e1c9d5c7ddca788b9c6edc72f0a9dd
EDI collectors like VintfDeviceInfo and VendorApexDeviceInfo need to
access to VINTF information. Instead of directly accessing related
files, we expose processed VINTF via /system/bin/vintf.
Bug: 336577802
Test: /system/bin/vintf
Change-Id: Id2b2e9b905bcb168638c60c2dc92ca550ed1558f
