The build system default was changed to not support apex, but
we want the mainline device to enable it.
Test: make mainline_system
Merged-In: I9f29e8354acffb1856dfd8a173b80a3f9324630c
Change-Id: I9f29e8354acffb1856dfd8a173b80a3f9324630c
Adds the backend makefile parser for the LOCAL_FUZZ_DATA vars generated
by the cc_fuzz target.
Bug: 141026328
Test: m example_fuzzer, fuzz target should have adjacent corpus/dict
files.
Change-Id: Ide2c34318f11be132992650ce5cc1fd27895915c
Only common files can reside in system partition, other files
should be moved to the newly added system_ext partition.
Note that for GSI, it will be a single system.img that includes the
contents of product and system_ext partitions, under /system/product
and /system/system_ext, respectively. After moving skip_mount.cfg to
system_ext partition, it also needs a symlink file under system
partition:
/system/etc/init/config -> /system/system_ext/etc/init/config
This allows Q-launched first-stage init (in /boot partition) continue
to use the same path when new GSI image is used.
Bug: 138281441
Test: build aosp_arm64-userdebug and boot it on crosshatch
Test: rm -rf out && build/soong/soong_ui.bash --make-mode \
TARGET_PRODUCT=aosp_arm64 TARGET_BUILD_VARIANT=userdebug droid
Change-Id: Iae9f5fb688f49497563864eb882d5f0ae33c744a
Only common files can reside in system partition, other files
should be moved to the newly added system_ext partition.
Note that for GSI, it will be a single system.img that includes the
contents of product and system_ext partitions, under /system/product
and /system/system_ext, respectively. After moving skip_mount.cfg to
system_ext partition, it also needs a symlink file under system
partition:
/system/etc/init/config -> /system/system_ext/etc/init/config
This allows Q-launched first-stage init (in /boot partition) continue
to use the same path when new GSI image is used.
Bug: 138281441
Test: build aosp_arm64-userdebug and boot it on crosshatch
Change-Id: Ida7c2d1b0152c7ef77fa9aeb5d0766d17aec59c5
This reverts commit ef7e3f2623.
The configuration affects GSI to have separate partitions for product
and system_ext which was not intended.
Bug: 138742524
Bug: 138382074
Test: emulator; check boot
Change-Id: Ie621d6b49f22ee2775adf1c1497e812f840f8ba7
Now that ONE_SHOT_MAKEFILE no longer exists, we don't have to rely on
the filesystem to store this informtion.
This removes ~16.7k files from our build graph
(aosp-master/aosp_arm64-eng), though only about 600 of them were being
used in a normal build.
Test: treehugger
Change-Id: I3ac12f5ea7f11d25064109a0599bc5be1976fba5
Now that mm/ONE_SHOT_MAKEFILE have been removed, we can expect to know
about all of our dependencies at the end of the build.
This removes 19k nodes from our build graph (aosp-master
aosp_arm64-eng), though in a default build, only 3k of those are used.
Test: ALLOW_MISSING_DEPENDENCIES=true, then trigger a missing dependency
Test: treehugger
Test: create link_type files, then apply CleanSpec.mk, ensure they're removed
Change-Id: I9506331e4a9911d2f26e59a2f72a97aef1644073
Build product and system_ext image and add them to super partition.
Bug: 138382074
Test: boot emulator and check system_ext partition mounted
Change-Id: Ifa67bd6ad475ac5912e8f919c7a771c9958bd5c2
Merged-In: Ifa67bd6ad475ac5912e8f919c7a771c9958bd5c2
Build product and system_ext image and add them to super partition.
Bug: 138382074
Test: boot emulator and check system_ext partition mounted
Change-Id: Ifa67bd6ad475ac5912e8f919c7a771c9958bd5c2
Merged-In: Ifa67bd6ad475ac5912e8f919c7a771c9958bd5c2
(cherry picked from commit 28843c3e32)
Libcameraservice is only used by cameraserver, and is explicitly listed
as a dependency. Libcamera_client is used by multiple places, but each
of them lists it as a depedency as well, so it's not needed here.
Removing the unused 64-bit version of libcameraservice will save ~2 MB
on the system partition.
Bug: 138403869
Test: atest CtsCameraTestCases
Merged-In: I196f869350900e7cc1521bc397c6ecff28decb6f
Change-Id: I196f869350900e7cc1521bc397c6ecff28decb6f
Build product and system_ext image and add them to super partition.
Bug: 138382074
Test: boot emulator and check system_ext partition mounted
Change-Id: Ifa67bd6ad475ac5912e8f919c7a771c9958bd5c2
Libcameraservice is only used by cameraserver, and is explicitly listed
as a dependency. Libcamera_client is used by multiple places, but each
of them lists it as a depedency as well, so it's not needed here.
Removing the unused 64-bit version of libcameraservice will save ~2 MB
on the system partition.
Bug: 138403869
Test: atest CtsCameraTestCases
Change-Id: I196f869350900e7cc1521bc397c6ecff28decb6f
The build system default was changed to not support apex, but
we want the mainline device to enable it.
Test: make mainline_system
Change-Id: I9f29e8354acffb1856dfd8a173b80a3f9324630c
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
Merged-In: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
(cherry picked from commit 6c62884000)
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
Merged-In: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
(cherry picked from commit 6c62884000)
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
