Mainline modules are not supposed to rely on 'on' action triggers in
their init scripts because events/properties are not guranteed to be
stable across many devices.
To reduce the potential risk of enabling 'on' for APEXes, for now, we
enable it for only Vendor APEXes.
When an init script in a non-Vendor APEX contains 'on' section, init
emits an error on parsing the script and skip the section.
For example, when init.rc in the ADBD APEX has 'on' section,
the following error is emitted on parsing the script.
init: Parsing file /apex/com.android.adbd/etc/init.rc...
init: /apex/com.android.adbd/etc/init.rc: 8: ParseSection() failed:
'on' is supported for only Vendor APEXes.
Bug: 232543017
Test: see above
Change-Id: I6509c8d2c6b632369d215128f740f9ed78858605
merge_op_start_ is used to set the iterator for merge operations.
Uninitialized value can potentially lead to setting up
of bad iterator.
Bug: 233246309
Test: Full OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I3cc48a66b532cfe8b2d87c8724d77ab3169a2ddb
The code previously assumed that write() took a non-zero number of clock
ticks. This is mostly true, but can't be guaranteed. Add a check to
avoid crashing if it's 0.
Bug: 233008287
Test: Compile
Change-Id: Idec0052f534dc4abb81a414ca76f6c11f4a4dded
We have a case where a service is requested to be started and does
not appear to be running, but we see no indication that it is
actually starting. This log should be enough information to see
if init is in a bad state.
Bug: 232297944
Test: doesn't add too much spam
~/android/aosp/system/core/init :) adb logcat -d | grep "requested start" | wc -l
42
Change-Id: Ic07f250c98b200b9e5b4432200c3668c6ca0ff35
The SELinux type of /data/media has changed from media_rw_data_file to
media_userdir_file, but the recursive restorecon of /data happens too
late when taking an upgrade. Add a restorecon of /data/media to just
above the chattr command which needs the new label to be allowed. This
doesn't "really" matter, since the chattr command is only needed just
after the directory was created anyway, but this fixes a SELinux denial.
Bug: 156305599
Bug: 232824121
Change-Id: I897be19ceb4686511469bdf7efda2483f298eee4
The VMCompilationPerformance profile is used to run Isolated Compilation
in a Protected VM, normally during the device idle, where relevant
APEXes are staged.
The original VMCompilationPerformance introduced in aosp/2060891 does
not have any specific definition and requires vendors to customize it.
This change re-defines it as an aggregated profile with a default set of
existing profiles, so that performance can be reasonable by default.
This profile may be renamed to a more generic name later, e.g.
"SCHED_SP_COMPUTE".
Bug: 231437770
Test: Run `composd_cmd test-compile` on a local device.
Before: 1m50s +/- 10s (with whatever that's default)
After: 1m25s +/- 5s
Change-Id: Ib8cd65782c818474fb129efbd9ef9a3e23ad1eb3
All the individual directories being treated specially by
FscryptInferAction() already have an explicit encryption action in the
corresponding mkdir commands. The explicit action is the source of
truth, so the special cases in FscryptInferAction() are unnecessary.
Also, some of these cases were outdated. For example, /data/app-staging
was changed from encryption=None to encryption=DeleteIfNecessary at some
point, but FscryptInferAction() was not updated. This is causing the
warning "Inferred action different from explicit one" to be logged.
Additional "Inferred action different from explicit one" warnings are
logged due to subdirectories of /data/apex being explicitly encrypted.
Change FscryptInferAction() to only do what it needs to do: check
whether the directory is a top-level directory of /data or not. Remove
the above-mentioned warning which is not useful.
Bug: 232554803
Change-Id: If6611d64107a19d242892c92dfea095577e193e5
To determine the default encryption action, the mkdir command checks
whether the given path is a top-level directory of /data. However, it
assumed a path without any duplicate slashes or trailing slash(es).
While everyone *should* be providing paths without unnecessary slashes,
it is not guaranteed, as paths with unnecessary slashes still work
correctly for all other parts of the mkdir command, including the
SELinux label lookup and the actual directory creation. In particular,
the /data/fonts directory is being created using 'mkdir /data/fonts/'.
The effect is that the mkdir command thinks that /data/fonts/ is *not* a
top-level directory of /data, so it defaults to no encryption action.
Fortunately, the full command happens to use "encryption=Require", so we
dodged a bullet there, though the warning "Inferred action different
from explicit one" is still triggered.
There are a few approaches we could take here, including even just
fixing the /data/fonts/ command specifically, but I think the best
solution is to have mkdir clean its path at the very beginning. This
retains the Linux path semantics that people expect, while avoiding
surprises in path processing afterwards. This CL implements that.
Note, this CL intentionally changes the behavior of, and thus would
break, any existing cases where mkdir is used to create a top-level
/data directory using a path with unnecessary slashes and without using
an explicit encryption action. There are no known cases where this
already occurs, however. No cases exist in platform code, and vendor
init scripts shouldn't be creating top-level /data directories anyway.
Test: atest CtsInitTestCases
Test: Booted and verified that a trailing slash is no longer present in
the log message "Verified that /data/fonts/ has the encryption
policy ...". Also verified that the message "Inferred action
different ..." is no longer present just above it.
Bug: 232554803
Change-Id: Ie55c3ac1a2b1cf50632d54a1e565cb98c17b2a6a
Bug:231647359
Test:call ensure_path_mounted("/data") in WipeData function in recovery then factory reset
Change-Id: Ia5b669319776fae9478534484e3993c15fe4e6bf
Although metadata encryption makes the device encryption policy
redundant, for now it is still being used, and the rule is still that
every top-level directory in /data is encrypted by the device policy
unless there is a specific reason why the directory can't be encrypted.
There are various cases where encryption=None is legimately needed and
is used, but they aren't explained in the code, and the option is prone
to be copy-and-pasted (as was done in https://r.android.com/1932960).
Fix this by explicitly commenting every case where encryption=None is
used, and consolidating the creation of all the user parent directories
into one place. (I left /data/bootanim as-is since it will be changed
to encrypted; see b/232299581.)
Change-Id: I6db5f4be7774e3d250c370638e8e7e33e226f3e7
Directories should always be encrypted unless there is a specific reason
they can't be. /data/bootanim is unencrypted without a specific reason,
so fix it to be encrypted. It is too late to use encryption=Require.
However, the contents of this directory doesn't need to be preserved on
updates, so we can use encryption=DeleteIfNecessary instead of
encryption=Attempt.
Bug: 232299581
Test: build success
Change-Id: I17bcb901ad533cada4e0aa061196fc94d7b213ec
This simplifies most of the calls to avoid doing any Android
specific code.
Bug: 120606663
Test: All unit tests pass.
Change-Id: I511e637b9459a1f052a01e501b134e31d65b5fbe
No longer needed as the code to generate flag files based on
this environment variable is removed in Android 13.
Bug: 231946889
Test: Build and boot,
Change-Id: I8ce57619aa4d1e6457f3f864bf5e403f727c040c
Since apexd.status=ready is system-only property, we need a similar or
equivalent event or property which non-system APEXes can use to define
'on' trigger actions.
Note that services can be started without its own trigger actions by
setting 'class'. For example, 'hal'-class services are started 'on boot'
automatically.
Bug: 202731768
Test: atest CtsInitTestCases
Test: atest CtsBluetoothTestCases (cuttlefish's bt apex defines
'on' actions in the APEX config)
Change-Id: I6eb62ba8d6e350add2ebafe7da06fcaa57d825ff
Instead of using config file path, use APEX's preinstalled path to
determine whether to use subcontext or not for APEX configs.
Bug: 232021354
Test: CtsInitTestCases, CtsBluetoothTestCases
Change-Id: Iba603f09602f0bec3113e2be3d15c62055c09e72
