summaryrefslogtreecommitdiff
path: root/init/builtins.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge "Revert "Reland: "init: run property service in a thread"""Tom Cherry2019-08-281-10/+0
|\
| * Revert "Reland: "init: run property service in a thread""Tom Cherry2019-08-281-10/+0
| | | | | | | | | | | | | | | | This reverts commit 8efca4bbb378ff5bd3af06d8511ea75a7ed49f99. Reason for revert: Still broken Change-Id: I3b37b1b00ff4b19f2eec2d8bd72042463d47cee3
* | Merge "Reland: "init: run property service in a thread""Tom Cherry2019-08-281-0/+10
|\|
| * Reland: "init: run property service in a thread"Tom Cherry2019-08-261-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's been a long standing issue that init cannot respond to property set messages when it is running a builtin command. This is particularly problematic when the commands involve IPC to vold or other daemons, as it prevents them from being able to set properties. This change has init run property service in a thread, which eliminates the above issue. This change may also serve as a starting block to running property service in an entirely different process to better isolate init from handling property requests. Test: CF boots, walleye boots, properties are set appropriately Change-Id: I13b8bf240c9fcb1d2d5890a8be2f0ef74efd4adf
* | Merge changes I1c1445ba,Ic0c8b163Paul Crowley2019-08-271-34/+47
|\ \ | | | | | | | | | | | | | | | * changes: Straighten out do_mkdir Convert fscrypt_set_directory_policy to C++
| * | Straighten out do_mkdirPaul Crowley2019-08-261-34/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | Use lstat(), and then make only the system calls needed to fix the directory up. Bug: 140027478 Test: boots twice, no worrying log messages. Change-Id: I1c1445baae3ec1c1ce17626ede388aa04d5f7781
| * | Convert fscrypt_set_directory_policy to C++Paul Crowley2019-08-261-1/+1
| | | | | | | | | | | | | | | | | | Bug: 140027478 Test: compiles, boots Change-Id: Ic0c8b163fe37b11787cab49cc2eea38a1de377e9
* | | Merge "Move fscrypt_init_extensions into system/core"Treehugger Robot2019-08-261-1/+1
|\| | | |/ |/|
| * Move fscrypt_init_extensions into system/corePaul Crowley2019-08-261-1/+1
| | | | | | | | | | | | Bug: 140027478 Test: treehugger Change-Id: I9f8b76a501be0b261b6fdd1da98447601e0fd32b
* | Revert "init: run property service in a thread"Tom Cherry2019-08-261-24/+1
|/ | | | | | | | | This reverts commit 26f5e7da3a8d99813d1db00bfb04e4ccd49e3221. Reason for revert: bluecross boot stability issue Bug: 140009641 Change-Id: I7ddb9509dfb2c6f644037129aa9d3fb9ff1740aa
* init: run property service in a threadTom Cherry2019-08-211-1/+24
| | | | | | | | | | | | | | | | | It's been a long standing issue that init cannot respond to property set messages when it is running a builtin command. This is particularly problematic when the commands involve IPC to vold or other daemons, as it prevents them from being able to set properties. This change has init run property service in a thread, which eliminates the above issue. This change may also serve as a starting block to running property service in an entirely different process to better isolate init from handling property requests. Test: CF boots, walleye boots, properties are set appropriately Change-Id: Id9534a5916abb2f7d2a49cda54e33c1b69c50c2f
* Revert "init: Handle properties in the background of calling fs_mgr"Tom Cherry2019-08-151-21/+6
| | | | | This reverts commit 71bdf2820ee0fbf698840f84fdd1255dbf8d3aee. Test: boot
* Merge "init: ignore ENOENT from fewer builtins"Tom Cherry2019-08-061-11/+46
|\
| * init: ignore ENOENT from fewer builtinsTom Cherry2019-07-301-11/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we were ignoring ENOENT from all builtins as rootdir/init.rc has many legacy commands that we need to keep for backwards compatibility, but are otherwise no longer relevant. However, this wasn't catching actual issues, for example chown failing due to not finding the user or group name. This change therefore reduces the scope of ignoring ENOENT to the only the extraneous errors in builtins. Test: boot CF and walleye without seeing errors from init.rc Test: see errors from invalid users/groups in chown Change-Id: Ia8e14fa2591e083cb1736c313a3e55515bc5d15e
* | init: check the arguments of builtins during the buildTom Cherry2019-08-011-43/+20
|/ | | | | | | | | | | | | Host init verifier already checks that the names and number of arguments for builtins are correct, but it can check more. This change ensures that property expansions are well formed, and that arguments that can be parsed on the host are correct. For example it checks that UIDs and GIDs exist, that numerical values can be parsed, and that rlimit strings are correct. Test: build Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
* init: simplify keyword_mapTom Cherry2019-07-231-2/+2
| | | | | | | | | | | I've heard that keyword_map is too complex, in particular the tuple and the pair in BuiltinFunctionMap, so this change removes a lot of that complexity and, more importantly, better documents how all of this works. Test: boot, init unit tests Change-Id: I74e5f9de7f2ec524cb6127bb9da2956b5f307f56
* Ignore class_{reset|start}_post_data on non-updatable APEX.Martijn Coenen2019-07-171-0/+13
| | | | | | | | | | | | | | | For devices that use FDE and don't support updatable APEXes, don't stop and restart all processes - there is no need and it only increases boot time for these devices. Additionally, some daemons have never been restarted in the past, and restarting them exposes certain issues. Bug: 137251597 Bug: 136777273 Bug: 135627804 Test: verified manually w/ ro.updatable.apex=false Change-Id: I9590f2c2cdfab0a49f39846896460305d44221ee
* Fix a few clang-tidy issues and add NOLINT for othersTom Cherry2019-07-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | android-base: * Add NOLINT for expanding namespace std for std::string* ostream overload libdm: * Fix missing parentesis around macro parameters init: * Fix missing CLOEXEC usage and add NOLINT for the intended usages. * Fix missing parentesis around macro parameters * Fix erase() / remove_if() idiom * Correctly specific unsigned char when intended * 'namespace flags' should be signed, since 'flags' it signed for clone() * Add clear to property restore vector<string> to empty after move * Explicit comparison against 0 for strcmp Test: build Change-Id: I8c31dafda2c43ebc5aa50124cbbd6e23ed2c4101
* init: fix to avoid loading apex *.rc files twiceJooyung Han2019-07-051-1/+1
| | | | | | | Test: adb shell dmesg | grep "init: Parsing file /apex" shows a single entry for each APEX'es *rc file Change-Id: I9006cc3d0cb7bdfe7532279f29d8095b7d16a807
* init: clean up host_init_stubs a bitTom Cherry2019-06-261-1/+0
| | | | | | | | In retrospect, these always should have been header only. We don't need setgroups() anymore either, since we have the right symbols now. Test: build Change-Id: If6fbf6f8ee288ed261576207d90a7ec5674853f9
* init: remove last init.cpp globalTom Cherry2019-06-261-0/+2
| | | | | | | | | | By moving it into builtins.cpp..., but that's less bad than it is now, especially since this is defunct in code targeting Q+. Remove the guards that init.h isn't being included by other files too as it's not useful anymore. Test: build Change-Id: Ic564fcff9e8716ec924098b07a8c9d94ca25f960
* Split out ServiceList and ServiceParser from service.cpp/.hTom Cherry2019-06-261-0/+1
| | | | | | | These always should have been in their own files. Test: build Change-Id: I201109b5ee63016e78901bbfd404846d45e1d4e6
* init: Handle properties in the background of calling fs_mgrTom Cherry2019-06-241-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It's been a long standing problem that init calls fs_mgr functions synchronously and therefore stops handling properties, which causes deadlocks if either fs_mgr, or vdc, or vold attempt to set properties. Previous work, b/21904461, shows that there is a large performance penalty for adding any amount of locking to properties, so moving property service into its own thread generically is not a viable option. However, we can be sure that init is not setting properties while the fs_mgr functions are running, so we can poll the property socket in a thread while we call these functions. The other alternative would have been to separate the fs_mgr functions into smaller pieces and revisit the main init loop between each piece. Unfortunately, this would be difficult, since fs_mgr_mount_all() calls out to different processes via logwrapper, which synchronously polls on a logging FD from the child, among other complexities that would make this strategy much more difficult than it would be worth. Bug: 21904461 Test: device boots, including when setting property in fs_mgr_mount_all() Change-Id: Ib0b7123024035884f9d90f9b489c1e2f5a2e1707
* Merge "Read *.rc files from flattened APEX"Treehugger Robot2019-06-111-5/+10
|\
| * Read *.rc files from flattened APEXJiyong Park2019-06-101-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change fixes a bug that *.rc files in APEXes are not read when the APEXes are flattened. This was because init used "/apex/*@*/etc/*.rc" glob pattern to find the files, which gives 0 result with flattened APEXes; with flattend APEXes /system/apex is just bind-mounted to /apex, and therefore, the name@version directories don't exist. Fixing the issue by globing /apex/*/etc/*.rc and filter-out the paths with @ to avoid double parsing the *.rc files in case of non-flattend APEXes. Bug: 134067086 Test: revert I75ec6b69cca1cef071b50fac9a4cf8b8ceddb142 build sdk_gphone_x86_64 and record a video in the camera app. The recording works. `ps -A | grep media.swcodec` shows media.swcodec process. `atest CtsStatsdHostTestCases:android.cts.statsd.atom.UidAtomTests#testAudioState` passes Test: build sdk_phone_x86_64 and do the same. Change-Id: I00af1910a8e8a330addc4c6903e5f3695aeb6865
* | init: replace Result<Success> with Result<void>Tom Cherry2019-06-101-121/+121
|/ | | | | | | | | | | Now that Result<T> is actually expected<T, ...>, and the expected proposal states expected<void, ...> as the way to indicate an expected object that returns either successfully with no object or an error, let's move init's Result<Success> to the preferred Result<void>. Bug: 132145659 Test: boot, init unit tests Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
* init: Refactor selinux.h/cppVic Yang2019-05-291-0/+1
| | | | | | | | | | | This change factors out functions that handle selabels from selinux.h/cpp into selabel.h/cpp. This allows util.cpp to be used by the upcoming native zygote without a bunch of define flags that are required for selinux.cpp. Bug: 133443795 Test: Build and boot cuttlefish. Change-Id: Ie238a96c6407c6698a605dd8803c1727abfaae7b
* init: don't import rc files during mount_all after QTom Cherry2019-05-211-1/+3
| | | | | | | | | | | | | Importing rc files during mount_all was at best a stop gap until Treble's first stage mount and at worst a bad idea. It doesn't have a reason to exist now that first stage mount exists and is required, and always had edge cases where init could not handle loading some aspects of scripts after it had started processing actions. This change removes this functionality for devices launching after Q. Test: devices boot Change-Id: I3181289572968637b884e150d36651f453d40362
* class_start_post_data also starts disabled services.Martijn Coenen2019-05-161-12/+13
| | | | | | | | | | | | | | | | | This keyword was introduced to support restarting services on devices using APEX and FDE. The current implementation is not a restart, but rather a 'reset' followed by a 'start', because the real /data must be mounted in-between those two actions. But we effectively want this to be a restart, which means that we also want to start 'disabled' services that were running at the time we called 'class_reset_post_data'. To implement this, keep track of whether a service was running when its class was reset at post-data, and start all those services. Bug: 132592548 Test: manual testing on FDE Taimen Change-Id: I1e81e2c8e0ab2782150073d74e50e4cd734af7b9 Merged-In: I1e81e2c8e0ab2782150073d74e50e4cd734af7b9
* Merge "Support for stopping/starting post-data-mount class subsets."Martijn Coenen2019-05-071-4/+35
|\
| * Support for stopping/starting post-data-mount class subsets.Martijn Coenen2019-04-261-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On devices that use FDE and APEX at the same time, we need to bring up a minimal framework to be able to mount the /data partition. During this period, a tmpfs /data filesystem is created, which doesn't contain any of the updated APEXEs. As a consequence, all those processes will be using the APEXes from the /system partition. This is obviously not desired, as APEXes in /system may be old and/or contain security issues. Additionally, it would create a difference between FBE and FDE devices at runtime. Ideally, we restart all processes that have started after we created the tmpfs /data. We can't (re)start based on class names alone, because some classes (eg 'hal') contain services that are required to start apexd itself and that shouldn't be killed (eg the graphics HAL). To address this, keep track of which processes are started after /data is mounted, with a new 'mark_post_data' keyword. Additionally, create 'class_reset_post_data', which resets all services in the class that were created after the initial /data mount, and 'class_start_post_data', which starts all services in the class that were started after /data was mounted. On a device with FBE, these keywords wouldn't be used; on a device with FDE, we'd use them to bring down the right processes after the user has entered the correct secret, and restart them. Bug: 118485723 Test: manually verified process list Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
* | Vboot1.0: remove code to read verity state in userspaceTom Cherry2019-04-191-12/+0
|/ | | | | | | | | | The code to read verity state in userspace is deprecated in favor of having the bootloader read and report the state, so this change removes this now unused code. Bug: 73456517 Test: boot Change-Id: Ib626fd61850bce3016179ca92a9831c2ac29c032
* init: do not fork before doing (u)mount_all()Tom Cherry2019-04-171-80/+14
| | | | | | | | | | A fork() was historically added in case of fs_mgr crashing or leaking memory, but this should not be the case with fs_mgr, and a fork() only hides any such problem, instead of allowing us to address it directly. Test: boot Change-Id: If7ee4807757048258a6ea9a79a24cebbacc530cc
* init: add umount_all builtin.Yifan Hong2019-04-151-11/+47
| | | | | | | | | | | | | | | | | | | | | | | umount_all is the cleanup step for mount_all. In particular, the mount_all builtin creates a verity device, 'postinstall-verity', for the following line: system /postinstall ... ... slotselect_other,logical,avb_keys=... cppreopt umounts /postinstall but doesn't destroy the postinstall-verity device, causing OTA to fail (because it cannot destroy the system_[other] device). umount_all also destroy the verity device. Note that mount_all does not map system_[other]; it is mapped by first stage init. Hence, umount_all doesn't destroy it either. The OTA client is reponsible for unmapping the device itself. Bug: 129988285 Test: flash, boot, then check `dmctl list devices`, then OTA Change-Id: Id3ab65b3860b6ea6cfec310ab13652009c81f415 Merged-In: Id3ab65b3860b6ea6cfec310ab13652009c81f415
* Don't bind-mount bionic filesJiyong Park2019-03-141-9/+0
| | | | | | | | | | | | Bind-mounting of the bionic files on /bionic/* paths no longer required as there are direct symlinks from bionic files in /system partition to the corresponding bionic files in the runtime APEX. e.g., /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so Bug: 125549215 Test: m; devices boots Change-Id: I4a43101c3e3e2e14a81001d6d65a8a4b727df385
* Activate system APEXes earlyJiyong Park2019-03-051-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Boot sequence around apexd is changed to make it possible for pre-apexd processes to use libraries from APEXes. They no longer need to wait for the apexd to finish activating APEXes, which again can be done only after /data/ is mounted. This improves overall boot performance. Detail: This change fixes the problem that processes that are started before apexd (so called pre-apexd processes) can't access libraries that are provided only by the APEXes but are not found in the system partition (e.g. libdexfile_external.so, etc.). Main idea is to activate system APEXes (/system/apex/*.apex) before /data is mounted and then activate the updated APEXes (/data/apex/*.apex) after the /data mount. Detailed boot sequence is as follows. 1) init prepares the bootstrap and default mount namespaces. A tmpfs is mounted on /apex and the propagation type of the mountpoint is set to private. 2) before any other process is started, apexd is started in bootstrap mode. When executed in the mode, apexd only activates APEXes under /system/apex. Note that APEXes activated in this phase are mounted in the bootstrap mount namespace only. 3) other pre-apexd processes are started. They are in the bootstrap mount namespace and thus are provided with the libraries from the system APEXes. 4) /data is mounted. init switches into the default mount namespace and starts apexd as a daemon as usual. 5) apexd scans both /data/apex and /system/apex, and activate latest APEXes from the directories. Note that APEXes activated in this phase are mounted in the default namespaces only and thus are not visible to the pre-apexd processes. Bug: 125549215 Test: m; device boots Change-Id: I21c60d0ebe188fa4f24d6e6861f85ca204843069
* Refactor fs_mgr_update_verity_state()Tom Cherry2019-02-111-4/+21
| | | | | | | | | | | | | | | | fs_mgr_update_verity_state() has two callers with generally different intentions. One caller loops through all entries in the default fstab to set partition.<mount_point>.verified properties. The other caller is only interested in whether or a specific mount point has verity enabled. Given this, we refactor fs_mgr_update_verity_state() to fs_mgr_get_verity_mount_point() which takes a single FstabEntry and returns the mount point used for the dm-verity device or an empty option if verity is not enabled on that mount point. Test: adb-remount-test.sh test on blueline Change-Id: Ic7dd8390509e95b2931b21e544c919a544138864
* Merge "Add android::fs_mgr namespace for new Fstab code"Tom Cherry2019-01-311-0/+2
|\
| * Add android::fs_mgr namespace for new Fstab codeTom Cherry2019-01-301-0/+2
| | | | | | | | | | | | | | Should have been done a while ago, but better late than never. Test: treehugger Change-Id: I0ea6e8d459cd3f3b3ce2d00a7a6a9786d52c52dd
* | Proper mount namespace configuration for bionicJiyong Park2019-01-301-0/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL fixes the design problem of the previous mechanism for providing the bootstrap bionic and the runtime bionic to the same path. Previously, bootstrap bionic was self-bind-mounted; i.e. /system/bin/libc.so is bind-mounted to itself. And the runtime bionic was bind-mounted on top of the bootstrap bionic. This has not only caused problems like `adb sync` not working(b/122737045), but also is quite difficult to understand due to the double-and-self mounting. This is the new design: Most importantly, these four are all distinct: 1) bootstrap bionic (/system/lib/bootstrap/libc.so) 2) runtime bionic (/apex/com.android.runtime/lib/bionic/libc.so) 3) mount point for 1) and 2) (/bionic/lib/libc.so) 4) symlink for 3) (/system/lib/libc.so -> /bionic/lib/libc.so) Inside the mount namespace of the pre-apexd processes, 1) is bind-mounted to 3). Likewise, inside the mount namespace of the post-apexd processes, 2) is bind-mounted to 3). In other words, there is no self-mount, and no double-mount. Another change is that mount points are under /bionic and the legacy paths become symlinks to the mount points. This is to make sure that there is no bind mounts under /system, which is breaking some apps. Finally, code for creating mount namespaces, mounting bionic, etc are refactored to mount_namespace.cpp Bug: 120266448 Bug: 123275379 Test: m, device boots, adb sync/push/pull works, especially with following paths: /bionic/lib64/libc.so /bionic/bin/linker64 /system/lib64/bootstrap/libc.so /system/bin/bootstrap/linker64 Change-Id: Icdfbdcc1efca540ac854d4df79e07ee61fca559f
* Revert "Bionic libs and the dynamic linker are bind mounted"Jiyong Park2019-01-181-82/+0
| | | | | | | | | This reverts commit 2599088ff67c10c66a70d3741c41529d3e11c7f5. Reason: Breaks some 3p apps. Bug: 122920047 Test: run the app, login. Change-Id: Idea332b1f91e9d2ac6ebd3879da7820c8ba2284f
* Merge "init: Add support for GSI installations in first-stage mount."David Anderson2019-01-171-1/+6
|\
| * init: Add support for GSI installations in first-stage mount.David Anderson2019-01-161-1/+6
| | | | | | | | | | | | Bug: 121209697 Test: gsi boots Change-Id: I69db0f8e999da366e46728b1008602f543cd79f6
* | Load build sysprops earlyJiyong Park2019-01-151-1/+1
|/ | | | | | | | | | | | | | | | | */build.prop files are now loaded much earlier than before; from 'on post-fs' to the time when the property service is started which is before init starts the action loop. This ensures that all processes that are launched by init have a consistent view of system properties. Previously, the processes that started before 'on post-fs' were initially with the small number of sysprops loaded from */default.prop and then suddenly get additional sysprops from */build.prop while they are executing. Bug: 122714998 Test: device boots Change-Id: Ic07528421dfbe8d4f43673cea41175d33cfbf298
* Bionic libs and the dynamic linker are bind mountedJiyong Park2019-01-111-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change makes the bionic libs and the dynamic linker from the runtime APEX (com.android.runtime) available to all processes started after apexd finishes activating APEXes. Specifically, the device has two sets of bionic libs and the dynamic linker: one in the system partition for pre-apexd processes and another in the runtime APEX for post-apexd processes. The former is referred as the 'bootstrap' bionic and are located at /system/lib/{libc|libdl|libm}.so and /system/bin/linker. The latter is referred as the 'runtime' bionic and are located at /apex/com.android.runtime/lib/bionic/{libc|libdl|libm}.so and /apex/com.android.runtime/bin/linker. Although the two sets are located in different directories, at runtime, they are accessed via the same path: /system/lib/* and /system/bin/linker ... for both pre/post-apexd processes. This is done by bind-mounting the bootstrap or the runtime bionic to the same path. Keeping the same path is necessary because there are many modules and apps that explicitly or implicitly depend on the fact that bionic libs are located in /system/lib and are loaded into the default linker namespace (which has /system/lib in its search paths). Before the apexd is started, init executes a built-in action 'prepare_bootstrap_bionic' that bind-mounts the bootstrap bionic to the mount points. Processes started during this time are provided with the bootstrap bionic. Then after the apexd is finished, init executes another built-in action 'setup_runtime_bionic' which again mounts the runtime bionic to the same mount points, thus hiding the previous mounts that target the bootstrap bionic. The mounting of the runtime bionic (which is only for post-apexd processes) is hidden from pre-apexd processes by changing propagation type of the mount points to 'private' and execute the pre-apexd processes with a new mount namespace using unshare(2). If a pre-apexd process crashes and re-launched after the apexd is on, the process still gets the bootstrap bionic by unmounting the runtime bionic which effectively un-hides the previous bind-mounts targeting the bootstrap bionic. Bug: 120266448 Test: device boots Test: cat /proc/`pidof zygote`/mountinfo shows that /system/lib/{libc|libdl|libm}.so and /system/bin/linker are from the runtime APEX Test: cat /proc/'pidof vold`/mountinfo shows that the same mount points are from system partition. Change-Id: I7ca67755dc0656c0f0c834ba94bf23ba9b1aca68
* Add conditional class startingDaniel Rosenberg2019-01-091-0/+6
| | | | | | | | | | | | | This adds the ability to prevent a class from starting if a certain persistent property has been set to disallow it. A class will only load if there is not a property named persist.init.dont_start_class.[class name] set to 1. Test: Set a property called persist.dont_start_class.[class] to 1. Verify that the given class does not start Change-Id: I51c70ad635762ed77855d0509e630adb0aec0eb1
* Start using new C++ Fstab class widelyTom Cherry2018-12-121-3/+4
| | | | | | | | Bug: 62292478 Test: boot Test: adb-remount-test.sh Change-Id: Id4715af4c1f03e2cfc67de92d3ea58e933685e51
* Update fs_mgr_update_verity_state() for new C++ FstabTom Cherry2018-12-071-6/+3
| | | | | | Bug: 62292478 Test: boot and check verity state Change-Id: I4912a16ada9a6d72480d7ac905654b764c5d18b6
* Convert fs_mgr_swapon_all() to use the new Fstab structTom Cherry2018-12-031-6/+7
| | | | | | Bug: 62292478 Test: build Change-Id: Ifbde514bf73d3ce2f321326291daa025b6afac46
* Don't fail when no glob matchJiyong Park2018-11-161-1/+2
| | | | | | | | | | There can be no match when there is no APEX installed or no APEX is providing *.rc file. Don't fail in that case. Bug: 117403679 Test: m apex.test; m; device is is bootable Change-Id: Ib1c607ee2c156dc236da1df7df0c6663e8d899b2
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 06:17:56 +0000