VNDK will be frozen only if the VNDK version is less than or equal to
34. Otherwize do not freeze the VNDK libraries.
Bug: 297542516
Bug: 299867815
Test: lunch cf_x86_64_phone-next-userdebug; m
Change-Id: Icdd288f65c5f7bdb5b4899c8e96820c2a147a011
LOCAL_SOONG_INSTALL_SYMLINKS can now be set by the install_symlink
module type. The install_symlink module type doesn't set
LOCAL_SOONG_INSTALLED_MODULE because make tries to copy that file
around, which doesn't work with a symlink.
Bug: 205632228
Test: built and ran the emulator observed the /system/bin/hwservicemanager symlink is still there
Change-Id: I1ec355b5ae057d0b7fe167674d70da6a4d03f6b5
This reverts commit af76a98608.
Reason for revert: To fix regression test failure on 'WallpaperPickerGoogleTests'
Bug: 297301079
Change-Id: Id9eb21db31182c68551ef9e3c3d4d258879c541b
Bug: b/294871815
Change-Id: Id4c198f79a32b1b5a6a1a594cbb88f8df1623fe7
Test: built and flashed aosp device and launched ThemePicker
Test: ran all CTS tests per b/294871815#comment11 on aosp device with ThemePicker
We are working on a replacement for "adb sync" and it requires something
running on the device to send back a fingerprint of the filesystem.
This binary is intendend to be part of developers going forward so we
are adding it in all eng/userdebug builds.
The binary is 830k bytes.
Test: m install-clean ; m ; acloud create --local-image ; adb shell ls -l /system/bin/adevice_fingerprint
Change-Id: I98359cc37cffeffc7ffbfd61d6bc9a51ba318a99
A change is being made to properly track apex compat symlinks in
the installation logic, which causes the artifact path requirements
to start complaining about them. Exclude them from the artifact path
requirements.
Bug: 205632228
Test: m nothing
Change-Id: Ie975b7450574d41bb13bb2179edc31ba4edd413e
Revert submission 2718295-colefaust_track_apex_compat_symlinks
Reason for revert: To validate if this change is causing the build breakage.
Reverted changes: /q/submissionid:2718295-colefaust_track_apex_compat_symlinks
Change-Id: I781cd6869daaf5931c5fabb5ca109502b1b52b3e
A change is being made to properly track apex compat symlinks in
the installation logic, which causes the artifact path requirements
to start complaining about them. Exclude them from the artifact path
requirements.
Bug: 205632228
Test: m nothing
Change-Id: I46150c3b7a4eaac16c2daa80fec2a5640e32b61b
This reverts commit 286e55ad94.
Reason for revert: the com.android.threadnetwork module is merged to com.android.tethering module
Bug: 296211911
Change-Id: Id601ab8b6f160d8fc2b7a9720652842cc2c194ba
Device targets may set PRODUCT_EXTRA_VNDK_VERSIONS to include invalid
snapshot versions with the trunk-stable next configuration.
Ignore those versions that are less than or equal to the
PLATFORM_VNDK_VERSION.
Bug: 296488609
Test: lunch cf_x86_64_phone-next-userdebug; m nothing
Change-Id: I2ba9d7f41a0d75db034b1c08d15f2796ef9ed506
This reverts commit a1a7046533.
Reason for revert: the com.android.threadnetwork module is merged to com.android.tethering module
Bug: 296211911
Change-Id: I33195990307715315a3877910de0cf4582399d6c
llndk.libraries.txt is currently installed within VNDK APEX, while all
libraries are placed in system image, and list is still valid when VNDK
is deprecated. This change adds llndk.libraries.txt into the system
image, when VNDK is deprecated.
Bug: 290160925
Test: aosp_cf build succeeded with llndk.libraries.txt in the system
image
Change-Id: I3d5d22dbbc870a59c03fd2e3d0fad54c93f8751e
Previously, the "sdk" target was a minimal lunch target that only
included enough to build the sdk. But the "sdk_<arch>" targets
redirected to the "sdk_phone_<arch>" targets, which are much bigger
and capable of building a whole emulator.
Building the sdk on products that can build a whole device complicates
the rest of the build system (for example, it starts enforcing dexpropt
works)
Bug: 290798660
Test: m sdk dist sdk_repo device-tests platform_tests on sdk_x86_64-userdebug
Change-Id: I76f38cf19172a5f5fae423175d5e03670137a0df
Previously, the "sdk" target was a minimal lunch target that only
included enough to build the sdk. But the "sdk_<arch>" targets
redirected to the "sdk_phone_<arch>" targets, which are much bigger
and capable of building a whole emulator.
Building the sdk on products that can build a whole device complicates
the rest of the build system (for example, it starts enforcing dexpropt
works)
Bug: 290798660
Test: Presubmits
Change-Id: I0ec5110318c43a7feee0b88edbed1cab0b590a47
the sidecar issue in GSI was fixed.
Bug: 111538404
Test: presubmit
Change-Id: Ia48ce2e076edc4f13f85e58d9bbbe15b8e6a4438
Signed-off-by: Roman Kiryanov <rkir@google.com>
... in order to have window extension library included
especially on large screen devices.
Bug: 288624195
Test: atest SdkAvailabilityTest
Ignore-AOSP-First: Future release
Change-Id: I8d347917f002cefb4f297930370ac7ae847f4731
...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
We will deprecate flattened apexes. In this change, GSI-specific make
variable (PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES) is removed. The
variable was used to install both image/flattened apexes in the GSI, so
that it works on ro.apex.updatable devices and not-updatable devices.
Now, GSI will have only image APEXes in it.
Bug: 278826656
Test: lunch gsi_arm64-userdebug && m # no flattened apexes
Change-Id: I4702973d4ee75aa693e4e7f4e57577b77059dc09
The decision to support updatable APEX or not used to be SoC-specific
because updatable APEX (aka non-flattened APEX) requires some kernel
feature support like loopback device. Kernel was considered as part of
BSP then. Therefore, ro.apex.updatable property was in the vendor
partition.
However, with GKI, kernel is no longer SoC-specific. And most APEXes are
installed to the system partition, which means that the decision affects
how the system partition is built. Thus, this CL moves the property to
the system partition. This enables some partners who have been using
flattened APEX to be able to upgrade to non-flattened APEX without
having to upgrade the vendor partition.
Bug: 281007951
Test: check system/build.prop
Change-Id: I81874076862f6047b9daa14518b95adcb5275064
Allow product configuration of memtag target list by
moving the current set into a product variable instead of the various
.bp files.
The default list of memtag targets can be found in
build/make/target/product/memtag-common.mk
This is NFC as all targets in the list already have "memtag_heap: true"
in the build files.
Bug: 280343521
Test: no functional change
Change-Id: I5954fde05256e00a8e01c114ad522f50ed0cfa9f
This CL leverages the PRODUCT_IS_ATV build time variable to selectively
exclude the SoundPicker package from the PRODUCT_PACKAGES. This also
paves the way to approach the removal of other unused packages from TV.
Bug: 276897441
Test: make
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:413b614d0d7bc1b412c87672f995fabfadbb6bc8)
Merged-In: Ifb25c1f26df545d31fb80f8e43c217fa8806e021
Change-Id: Ifb25c1f26df545d31fb80f8e43c217fa8806e021
