Use Android-Apache-2.0 for all Apache 2.0
Remove legacy_restricted (no longer appears in code).
Remove Android.bp which did not build anything but was a placeholder
for the missing license texts.
Test: m nothing
Change-Id: Ia491a59c735ca20afda9b4bbac9d8b33dbf8874e
fs_config requires the information from the header files in
system/core and bionic/libc. To build the vendor side fs_config,
use the header files in the vendor snashot if the required version
exists.
Bug: 187222756
Test: check ninja depedency with and without snasphots.
Change-Id: Ibf96eab4d9a129745be1a19b2aa2e4c8f57cf6bf
These files were added to devices with the fs_config_files_nonsystem
module in base_vendor.mk. As they are partition-specific, move them
to each base_<partition>.mk file.
To add the fs_config_* files to the base_<partition>.mk files, it is
required to define the fs_config_* regardless of the existance of
partitions.
Bug: 170282998
Test: build and check if they are installed.
Change-Id: Ib8a2c75e2e0e93bb7030da981494e880f8465e5a
android_filesystem_config.h is found since system/core/include is on
the include path for all projects and contains a symlink to the real
android_filesystem_config.h. This is fragile and the below bug seeks
to remove this symlink and have users correctly depend on
libcutils_headers.
Bug: 165825252
Test: build
Change-Id: Ie921c4fd96d6e4e42d127bfbfe7a892756ad9495
If the device has neither an OEM nor a vendor partiton,
$PRIVATE_PARTITION_LIST will be empty, causing the fsconfig tool to fail
because the "--all-partitions" argument will be empty.
Quote the comma-substituted "$(PRIVATE_PARTITION_LIST)" - which may be
empty - to appease argparse, which will then populate "_all_partitions"
with an empty "str" object.
Checking _all_partitions against None is superfluous since either
argparse will catch the empty argument and fail early, or the argument
will be a string, in which case it will not be None.
Signed-off-by: Felix <google@ix5.org>
Change-Id: I236e30445b303b4945467b5dc4387d54b5d984f9
We want to remove target specific host tools and since
fs_config_generate is compiled with a target specific header file, we
instead remove fs_config_generate entirely and allow python to build
the fs_config_files/dirs files directly from config.fs files and
parsed C headers.
Test: associated unit tests and new end to end test
Test: aosp_sailfish, aosp_crosshatch build produces valid fs_config files
Test: aosp_cf_x86_phone build correctly produces empty fs_config files
Change-Id: Idbc63ff56c0979e1e4c17721371de9d9d02dc8ff
This was deprecated along with TARGET_ANDROID_FILESYSTEM_CONFIG_H so
warn if it still exists.
Test: successful error if it exists, no error if it does not
Change-Id: I7dde3c88aaf7ecec23ffe018cbe8b42ebadb2bf8
TARGET_FS_CONFIG_GEN has existed as the preferred mechanism for two
releases, so we finally deprecate TARGET_ANDROID_FILESYSTEM_CONFIG_H.
Test: build
Change-Id: I299a4d1d1d893ac16d6e6ce2ec4659bfcdc19095
Mechanical extension of mount directories to also support product/
and product_services/ as individually supplied images.
NB: In the distant past, a prototype placing the make rules into a
macro was rejected as too difficult to maintain within the macro
rules, so rules are rolled-out to make them easy to understand.
Test: compile
Bug: 119310326
Change-Id: Ief137cbe62db7175ee02275804ff1d644858dc3d
Content from fs_config designated for other partitions is leaking
into the system fs_config_* files. Notably /vendor is showing up.
Rule expansion happens late, after all parsing. This is the same in
make and kati. build/make/tools/fs_config/Android.mk ends with
fs_config_generate_extra_partition_list :=, so by the time you get to
rule expansion the value is empty.
Added a PRIVATE_PARTITION_LIST variable to record the value of
fs_config_generate_extra_partition-list.
Test: inspect result of ${OUT}/product/*/system/etc/fs_config_files
Bug: 119677224
Bug: 119310326
Change-Id: I968b4936ab2c5d174f164c760820af13434654ca
This was already done for partitions other than the system partition.
Add new, separate "_system" targets, and add new phony modules which
collects _system and _nonsystem targets for now.
Update the base_system.mk file to only depend on the system module, and
put the other ones in base_vendor.mk for now.
Bug: 80410283
Test: make fs_config_dirs[_*] fs_config_files[_*] and verify output
Change-Id: I7843578dbb9f27edf4c1e5b4a795a530f79e0be1
Previously we only created these if the device set
TARGET_FS_CONFIG_GEN, however there are now other targets that want to
depend on these. Instead of having those targets conditionally depend
on them, we always create them, defaulting to blank contents (by
reading /dev/null for TARGET_FS_CONFIG_GEN).
Test: builds succeed
Change-Id: Ie95286f5a800d891022eb66cd6fefcc967000c2e
These entries are vendor provided and belong on the /vendor partition.
Bug: 27999086
Test: end to end user/group check via config.fs and getpwnam, etc.
Change-Id: I9a5d56da594bf0d04de2b9ce7fd7d9a8151d4682
Clear fs_config_generate_extra_partition_list after use.
Test: build fs_config_files and fs_config_dirs targets.
Change-Id: Ie18bcd2df2ff1becb178e9ba45d226e2e9a8faab
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Misspelled fs_config_generate_extra_partition_list when used to
calculate LOCAL_REQUIRED_MODULES dependencies. This resulted in
fs_config_dirs and fs_config_files failing to generate the vendor,
oem or odm variants (ie: fs_config_files_vendor)
Test: build generates correct fs_config override files.
Bug: 37721445
Bug: 36071012
Change-Id: I053dd5cdb357c7cea05a5ff63b0686bd0bc99df6
Add build targets to generate the vendor, oem and odm slices of the
fs_config_dirs and fs_config_files targets for each of the respective
filesystems, and automatically trigger the individual and enabled
partition build objects based as dependents of fs_config_dirs and
fs_config_files.
Sensitive to the following board definition pairs:
BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE BOARD_USES_VENDORIMAGE
BOARD_OEMIMAGE_FILE_SYSTEM_TYPE BOARD_USES_OEMIMAGE
BOARD_ODMIMAGE_FILE_SYSTEM_TYPE BOARD_USES_ODMIMAGE
Which when defined and set means the images are generated for vendor,
oem or odm respectively.
Test: manually build w/ m 'fs_config_(dirs|files)_(vendor|oem|odm)'
and check the expected products, or fails if not pertinent.
Test: build for product that produces split to system and vendor and
subsequently boots with vendor products correctly configured.
Bug: 36071012
Change-Id: I44289a3dd50b7657367c826ad813c671a3de6afc
This reverts commit fad4b4b715.
Incorporating the following fixes:
1.
fsconfig: fix fs_config_* build for discovered headers
When android_file system_config.h is picked up from the device
directory, neither TARGET_FS_CONFIG_GEN or TARGET_ANDROID_FILESYSTEM_CONFIG_H
are specified. Thus, the build is not generating the required fs_config_files
and fs_config_dirs.
Test: Ensure that make fs_config_files works, and produces the same output as before
Build the system image and mount it as a loop back and dump the file system
capabilities with getcap. Verify that output to the supplied
android_file system_config.h
From the loopback of the system.img mount, from CWD system/bin:
$ getcap *
cnss-daemon = cap_net_bind_service+ep
hostapd = cap_net_admin,cap_net_raw+ep
imsdatadaemon = cap_net_bind_service+ep
ims_rtp_daemon = cap_net_bind_service+ep
logd = cap_setgid,cap_audit_control,cap_syslog+ep
mm-qcamera-daemon = cap_sys_nice+ep
pm-service = cap_net_bind_service+ep
run-as = cap_setgid,cap_setuid+ep
surfaceflinger = cap_sys_nice+ep
webview_zygote32 = cap_setgid,cap_setuid,cap_setpcap+ep
webview_zygote64 = cap_setgid,cap_setuid,cap_setpcap+ep
Compared to the android_filesystem_config.h:
{ 00700, AID_CAMERA, AID_SHELL, (1ULL << CAP_SYS_NICE), "system/bin/mm-qcamera-daemon" },
{ 00755, AID_SYSTEM, AID_SYSTEM, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/pm-service" },
{ 00755, AID_SYSTEM, AID_SYSTEM, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/imsdatadaemon" },
{ 00755, AID_SYSTEM, AID_RADIO, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/ims_rtp_daemon" },
{ 00755, AID_SYSTEM, AID_SYSTEM, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/cnss-daemon"},
2.
fsconfig: fix error message for duplicate AID
Fixes:
raise ValueError('Duplicate aid value "%u" for %s' % value,
TypeError: %u format: a number is required, not str
and
raise ValueError('Duplicate aid value "%s" for %s' % value,
TypeError: not enough arguments for format string
3.
fsconfig: add test for duplicate ranges
Add a test for duplicate range detection.
4.
fsconfig: skip AID_APP, AID_USER and all ranges
Do not output AID_APP, AID_USER and ranges. A range
is defined as ending with AID_ and ending in _START or
_END.
5.
fsconfig: test for skip AID_APP, AID_USER and all ranges
Test against AIDs that caused the bionic tests to fail.
Change-Id: I95569a9ccc83bd3231f8a6f395532cc2de316bd2
Signed-off-by: William Roberts <william.c.roberts@intel.com>
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>
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>
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 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>
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>
Introduce TARGET_FS_CONFIG_GEN, an option for generating
android_filesystem_config.h files from multiple intermediate
file formats. See the README for more details.
Change-Id: Ibdb2f65702657802e34b0cec18fb43709d7452bb
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Multiple files added to TARGET_ANDROID_FILESYSTEM_CONFIG_H will build,
however the tooling will only respect the first header found. The
sanity check in the makefile will only check the first path found for
proper naming convention. One can end up with a successful build that
does not respect all files in the TARGET_ANDROID_FILESYSTEM_CONFIG_H.
Check that one and only one item is set to
TARGET_ANDROID_FILESYSTEM_CONFIG_H variable.
Output:
*** Multiple fs_config files specified, see "device/lge/bullhead/two/android_filesystem_config.h device/lge/bullhead/one/android_filesystem_config.h"..
Change-Id: I70a43f44713b273cb9a78f54ff16854b9e11af4a
Signed-off-by: William Roberts <william.c.roberts@intel.com>
fs_config_generate_$(TARGET_DEVICE) is built based off the content
of $(TARGET_ANDROID_FILESYSTEM_CONFIG_H). We also add the rules
fs_config_dirs and fs_config_file to utilize this command
for target contents:
fs_config_generate_$(TARGET_DEVICE) -D -o system/etc/fs_config_dir
fs_config_generate_$(TARGET_DEVICE) -F -o system/etc/fs_config_file
In order to use this feature, one must have the fs_config_dirs and
fs_config_files in the $(PRODUCT_PACKAGES) list defined in the
device make files in $(TARGET_DEVICE_DIR). And either an
android_filesystem_config.h file in that directory, or define a
path in TARGET_ANDROID_FILESYSTEM_CONFIG_H to point to one.
Bug: 19908228
Change-Id: Iee1543d99169f874e0915ae07962a7750ecb6342
- move to libcutils.so and libselinux.so as shared now that
they are in DISTTOOL.
- liblog dependency is part of libcutils, and need not be
called out explicitly now. liblog is in DISTTOOL.
- libcutils fs_config has the right to add Android logging
Bug: 19908228
Change-Id: Iaa60ad624b42d83653840ac3c77bfa03ad8674aa
Update the OTA generation script to understand SELinux file
labels and file capabilities.
Make fs_config aware of SELinux labels and file capabilities, and
optionally output those elements whenever we output the
UID / GID / file perms. The information is emitted as a key=value pair
to allow for future extensibility.
Pass the SELinux file label and capabilities to the newly created
set_metadata() and set_metadata_recursive() calls. When the OTA
script fixes up filesystem permissions, it will also fix up the SELinux
labels and file capabilities.
If no SELinux label and capabilities are available for the file, use
the old set_perm and set_perm_recursive calls.
Bug: 8985290
Bug: 10183961
Bug: 10186213
Change-Id: I4fcfb2c234dbfb965cee9e62f060092a4274d22d
Make fs_config aware of SELinux contexts, and output the context
whenever we output the UID / GID / file perms.
Pass the selinux context to the set_perm2() and set_perm2_recursive()
calls. When the OTA script fixes up filesystem permissions, it will
also fix up the SELinux context on the files.
Bug: 8985290
Change-Id: I6419b64c06309a93ac6b2f2cf9fc7f8815adeaf3
