//visibility:any_system_partition, //visibility:any_vendor_partition,
etc.
Then, if a partition visibility rule is not specificed, but the module
is installed on a non-system partition via the `vendor: true` or other
properties, the visibility rule for that partition will be added by
default.
This is so that "any_partition" doesn't imply that modules could be put
on the vendor partition when they weren't designed for that, and so that
modules that do need to go on the vendor partition don't need to specify
both vendor: true and visibility:any_vendor_partition.
Eventually, the partition properties should be deprecated, and replaced
with just these visibility rules.
Bug: 321000103
Test: go tests
Change-Id: I24dba36bbc20921941f892480bf7c050e93827c6
android_system_image used GatherPackagingSpecs and then filter only
system modules. But some modules were omitted in this logic because
there are modules which has the same relative path, so the later one is
ignored even though its partition info is what we're looking for. So add
filter logic in GatherPackagingSpecs to avoid this problem
Bug: 323793487
Test: build android_system_image, and then check if it contains every
module we want
Change-Id: Iec8ae920736d3d1920eecad71ba0f8f2fe848e6c
android_system_image filers packaging items installed outside "system"
partition.
Some packaging items install related items to different partitions but
putting them altogether to android_system_image doesn't make sense.
(android_system_image is suppposed to be "system" partition)
To be specific, this filters out "apex" partition items. "apex"
partition is used by APEX installation to install APEX contents to paths
similar to activated paths on device so that symbol lookup works well
with APEX contents.
Bug: 225121718
Test: atest MicrodroidHostTestCases
Test: debugfs <intermediate>/microdroid.img -R 'ls system'
shows no "com.android.runtime"
Change-Id: Ibc3d85ead2fda99e231132ce8ab9ccf1cc9317b7
android_system_image module type is a specialization of the
android_filesystem module type. Currently, it adds a build rule for
creating linker.config.pb from the information about all the other files
in the filesystem and includes linker.config.pb to the filesystem as
well.
To do so, the filesystem module now provides a function pointer which
subtype modules like android_system_image can implement to pass extra
files that they want to package in the filesystem.
In addition, the linkerconfig package is revised to make it possible to
build linker.config.pb file outside of the package.
Bug: 185391776
Test: m microdroid and inspect etc/linker.config.pb in it.
Change-Id: Id89c40b519213062860d7306029b8413d8d36a2d
