This section will be modified as part of splitting these packages into platform
and non-platform components. Sort them all to avoid conflicts.
Bug: 31363362
Test: Builds
Change-Id: I91fb4d4d7c0a6971a19047ef2eb2981770a122ff
In two-step OTAs, we write recovery image to /boot as the first step so
that we can reboot from there and install a new recovery image to
/recovery. However, bootloader will show "Your device is corrupt"
message when booting /boot with the recovery image. Because the recovery
image encodes the path of "/recovery" as part of the signature metadata,
which fails the verified boot.
This CL generates a special "recovery-two-step.img" in addition to the
regular recovery.img. This image encodes "/boot" when being signed,
which will be flashed to /boot at stage 1/3 in a two-step OTA.
Here are the desired changes:
- 'IMAGES/recovery-two-step.img' exists in target_files.zip for non-A/B
targets (e.g. bullhead). The image should not exist for targets that
don't have a recovery partition (e.g. A/B devices like sailfish).
- <device>-img.zip should not contain 'recovery-two-step.img'.
- Nothing should change when building non-two-step OTAs. For two-step
OTAs, 'recovery-two-step.img' should be included in the OTA package;
'updater-script' should flash this image to /boot at stage 1/3.
- When building a two-step OTA with an input TF.zip that doesn't have
IMAGES/recovery-two-step.img, it should use the existing
IMAGES/recovery.img instead.
Bug: 32986477
Test: Tested the steps above on bullhead and sailfish.
Change-Id: I34e6c599bcf2011d4cd5c926999418b3975d6d0f
The 'system_img_path' parameter was introduced in commit
d995f4b04d, but became obsolete since
commit 2ce63edab7.
Test: m dist
Change-Id: Iffd496d929db5cc3dfc955a48bfc1b1317bd012f
This reverts commit a35d92e431.
The app_process__asan module is merged into app_process.
Bug: 33224213
Test: m
Change-Id: I5e3e836c67b5bd17cf967f1b2429e39c4e18557b
This reverts commit eee31511f7.
Rewriting of app_process adds an automatic dependency.
Bug: 33224213
Test: m
Change-Id: Idd9509d116692954224f4d2ffd6c81b69e9a85a3
Bug: http://b/28866258
Remove libbcc.so from the list of directly packaged modules. 64-bit
libbcc.so gets included as a dependency for the bcc executable (which is
a required package). 32-bit libbcc.so is no longer necessary on 64-bit
devices.
This change also removes 32-bit libLLVM.so from a 64-bit system image
(leading to a 13M reduction in Angler's system image on AOSP) and a
considerable reduction in build time.
Test: - Build all topics in this CL
- RsTest (including the 32-bit ABI) and CTS tests pass on x86 and
x86_64 emulators and Angler.
Change-Id: I10f07e322a615f37d6967b7c938635f544ddceff
Add asanwrapper helper binary to PRODUCT_PACKAGES when building with
SANITIZE_LITE=true.
Bug: 33224213
Test: m SANITIZE_TARGET=address SANITIZE_LITE=true && ls $OUT/system/bin/asanwrapper
Change-Id: Ic4d8973b9e9ddfd9ef8663735bf5f70d8f9f70e1
Add some initial unit tests.
The unit tests themselves are inlined into the tool and
can be executed by running the "test" commandlet.
Example:
$ python -m unittest test_fs_config_generator.Tests
.............
----------------------------------------------------------------------
Ran 13 tests in 0.004s
OK
Test: run the test commandlet and observe for failures.
Change-Id: I1bada385fa841fd50fa958997d440f1198e15198
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Add sanitized app_process module to PRODUCT_PACKAGES when building
with SANITIZE_LITE=true
Bug: 33224213
Test: m SANITIZE_TARGET=address SANITIZE_LITE=true && ls $OUT/system/bin/asan
Change-Id: Ic67976f1b897b638d569ec6f42d5a8d59f8a9285
When configuring fs_config_files or fs_config_dirs for file_system
capabilities, drop the requirement that OEMs must add the target
to PRODUCT_PACKAGES. This limits the configuration requirement
to only needing to set the new and preferred TARGET_FS_CONFIG_GEN
or the older TARGET_ANDROID_FILESYSTEM_CONFIG_H method.
Test: That only setting TARGET_FS_CONFIG_GEN results in passwd and
group in the build image.
Change-Id: I818854fa1b3e94edaff59a32bd7cf23cf9b504aa
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Setup PRODUCT_PACKAGES for the group file.
The group file is always included in the product
build but may be empty.
Test: That the group file is in the build.
Change-Id: I2ed1759fbe42a7e6833bb754b00cadaf949f128d
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Introduce a generator that outputs group files per man(5) group.
Succinctly, the output is a colon delimited string containing the following
fields:
* group name
* encrypted password (optional)
* gid (int)
* userlist (str,...)
Multiple colon delimited lines may exist, but will not be separated
across lines.
Sample generator output:
foo::2900:
foo_bar::2901:
custom_oem1::2902:
Test: That make group produces the group file.
Change-Id: Idd3fe925a09a227c6e894e1b5d2b3873b01531c6
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Setup PRODUCT_PACKAGES for the passwd file.
The passwd file is always included in the product
build but may be empty.
Test: That the passwd file is in the build image.
Change-Id: Iedbb81b15d3b281ff4ad36d28adc2ba4523785f2
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Introduce a generator that outputs passwd files per man(5) passwd.
Succinctly, the output is a colon delimited string containing the following
fields:
* login name
* encrypted password (optional)
* uid (int)
* gid (int)
* User name or comment field
* home directory
* interpreter (optional)
Multiple colon delimited lines may exist, but will not be separated
across lines.
When run, produces:
foo::2900:2900::/:/system/bin/sh
foo_bar::2901:2901::/:/system/bin/sh
custom_oem1::2902:2902::/:/system/bin/sh
Note that this generator allows for 0 or more config.fs files. This allows for:
* Unconditional inclusion of /system/etc/passwd in the generated image
* A blank passwd file if no config.fs files are specified.
This ensures that when OEMs add config.fs files, there is no additional steps
for proper functionality (simpler for OEMs).
The one draw back is the additional inode consumption on system for a possible
blank file.
Test: That it produces a valid passwd file.
Change-Id: I19691c8260f02147ed861f8a319aeab3f5b1738e
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Generate the friendly name in one location. This prepares
the tool for generatting passwd and group files.
Also support mapping friendly names to identifiers.
Test: That output files stay the same as before.
Change-Id: I12198611126613eae81ca61614ed269c2439b72b
Signed-off-by: William Roberts <william.c.roberts@intel.com>
When generating files restrict the characters allowed in
AID_<name> to upercase, numbers, and underscores.
This detects errors ahead of time for generated C files as
well as handles seperation characters for passwd/group files.
This also lends itself to automatic detection of collisions
on friendly names, since freindly names are the lowercase
version of <name>.
Test: That invalid aid values result in a build failure.
Test: That the output files are consistent with ones before
this change (hash and diff checks)
Change-Id: Ie8ec44c1157ba9c22100e9169d9187f615e71280
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Generate an OEM AID_<name> header file seperate from fs_config
header file and provide details on how to export this interface
into native code.
Test: That ls, ps, chown and services function for built in
services as before.
Change-Id: Ie8ce6585e0721b52633ee50d62dcfe796e178f65
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Implement an android_id generator that takes the data
acquired from parsing private/android_filesystem_config.h
and generates the android_id friendly name to uid mapping
for consumption in Bionic.
Test: That ls, ps, mkdir, chown, chgrp and services for built
in names work.
Change-Id: I1e55a401be0fca0ad162f8dc1e072e6afde7b927
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Rather than hardcode the OEM ranges, parse and extract
AID values from android_filesystem_config.h.
An AID is defined to the tool as:
* #define AID_<name>
An OEM Range is defined to the the tool as:
* AID_OEM_RESERVED_START
* AID_OEM_RESERVED_END
or
* AID_OEM_RESERVED_N_START
* AID_OEM_RESERVED_N_END
Where N is a number.
While parsing, perform sanity checks such as:
1. AIDs defined in the header cannot be within OEM range
2. OEM Ranges must be valid:
* Cannot overlap one another.
* Range START must be less than range END
3. Like the C preproccessor, multiple matching AID_<name> throws
en error.
The parser introduced here, prepares the tool to output android_ids
consumable for bionic.
Note that some AID_* friendly names were not consistent, thus a small
fixup map had to be placed inside the tool.
Test: tested parsing and dumping the data from android_filesystem_config.h
file.
Change-Id: Ifa4d1c9565d061b60542296fe33c8eba31649e62
Signed-off-by: William Roberts <william.c.roberts@intel.com>
This internally structures fs_config_generator.py to be able
to plug in generators to produce different outputs. This
prepares this tool for group and pwd file outputs.
Test: Checked diff and hash of before and after files.
Change-Id: Ie558518ac227dd946d70ab48027698b72a9bc94a
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Building with LOCAL_STATIC_ANDROID_LIBARIES and LOCAL_USE_APPT2
causes a warning:
build/core/package_internal.mk:143: Empty argument supplied to find-subdir-assets
Only call find-subdir-assets if my_res_dir is not empty.
Also improve the warning message to make it easier to find the module
that caused it.
Test: m -j
Change-Id: I9a71162c7e2ed82f64d6844baca256968ac77317
There are no users left, so remove all of this.
Test: lunch aosp_arm-eng; m -j native
Test: build/tools/kati_all_products.sh on aosp and internal master
Change-Id: I32f5c8b470a43dd203d7e20c192167630e4e6888
Add BOARD_VNDK_VERSION and LOCAL_USE_VNDK to specify the version of the
VNDK that will be used globally, and whether to use the VNDK on a module
basis.
If the board is using the VNDK:
* LOCAL_COPY_HEADERS may only be used by modules defining LOCAL_USE_VNDK
* LOCAL_USE_VNDK modules will compile against the NDK headers and stub
libraries, but continue to use the platform libc++.
* LOCAL_USE_VNDK modules will not have the global includes like
system/core/include, but it will use device-specific kernel headers.
This change does not attempt to enforce any linking constraints, that
will come in a later patch.
Test: out/build-aosp_arm.ninja is identical before/after
Change-Id: Icce65d4974f085093d500b5b2516983788fe2905
