Bazel's intermediates/inputs are symlinks in its execution root, unlike Soong.
e.g.
$ file $(readlink -f out/bazel/output/execroot/__main__/packages/modules/adb/apex/adbd.rc)
/usr/local/google/home/jingwen/aosp/master-with-phones/packages/modules/adb/apex/adbd.rc:
ASCII text
Test: presubmits
Change-Id: I3977a37ee989e07bee56abb019a21055b8cef567
ParseApexConfigs() uses Parser::ParseConfigFile() to parse .rc files in
the target apex. ParseConfigFile() returning bool (with logging on
error) doesn't propagate the error message back to the callers
(including apexd or PackageManager).
We'd better to migrate other Parse*() methods of Parser class to return
Result<T>. But this change focuses on plumbing error progagation for
APEX configs.
Bug: 238820991
Test: atest CtsInitTestCases
Change-Id: Ifad97635dbb53a70053ec73a7a5b7e742466daf6
Includes extracting the APEX-specific SDK version naming scheme filter
logic so it can be reused when host_apex_verifier looks at rc files
inside the APEX.
Bug: 222121216
Test: Use in host_apex_verifier
Change-Id: I0396a455f30d2de71525ccd3fa69c75576054048
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 now parses *.rc files from the APEXs when the apexd notifies the
mount event via apexd.status sysprop.
Bug: 117403679
Test: m apex.test; adb root; adb push <builtfile> /data/apex; adb reboot
adb root; adb shell setprop ctl.start apex.test; dmesg shows that init
tries to start the service which doesn't exist.
[ 47.979657] init: Could not ctl.start for 'apex.test': Cannot find '/apex/com.android.example.apex/bin/test': No such file or directory
Change-Id: I3f12355346eeb212eca4de85b6b73257283fa054
Also get rid of the copy in parser. There's no incentive to switch to
a tokenizer that doesn't modify the input, nor is there a reason to
waste cycles making a copy of every init script as its processed.
Bug: 36970783
Test: boot
Change-Id: I8aca9c9d6f1961e1ab35dee50691a6791fc6ec66
Allow specifying properties on the command line when running host init
verifier. This is needed particularly for importing files that have a
property expansion in their path.
Handle the import statement on host, basing paths off of the out
directory of Android builds.
Bug: 36970783
Test: verify that bullhead imports the correct files and checks them
Change-Id: I4fe263016b3764a372708b559bc0c739b1b7e5e3
Create a host side parser for init such that init rc files can be
verified for syntax correctness before being used on the device.
Bug: 36970783
Test: run the parser on init files on host
Change-Id: I7e8772e278ebaff727057308596ebacf28b6fdda
Allow it to fail. When there is an error for a section ending,
print the error pointing to the line where the section starts.
Bug: 69050941
Test: boot, init_tests
Change-Id: I1d8ed25f4b74cc9ac24d38b8075751c7d606aea8
* Remove the Parser singleton (Hooray!)
* Rename parser.* to tokenizer.* as this is actually a tokenizer
* Rename init_parser.* to parser.* as this is a generic parser
* Move contents of init_parser_test.cpp to service_test.cpp as this
actually is a test of the parsing in MakeExecOneshotService() and
nothing related to (init_)parser.cpp
Test: boot bullhead
Test: bool sailfish
Test: init unit tests
Change-Id: I4fe39e6483f58ebd3ce5ee715a45dbba0acf5d91
Now that ueventd is using init's parser, we no longer need anything
other than the tokenizer from parser.cpp.
Test: Boot bullhead
Change-Id: I1f70f2c4479af576174bd74dd919d81817500216
To prevent clashing with forthcoming changes to uevent_parser.c
Change-Id: I2ee183261c7f43e0e4104a16a280c7ee73d7df96
Signed-off-by: Greg Hackmann <ghackmann@google.com>
If we process the import directive inline, then the ordering of the
commands for the "on xxx" sections would be a little unexpected. The
init.rc files do not really have an implied order as to which section
appears and gets processed first. The init code itself provides that
ordering explicitly. For the user, the expectation is that if both the
current file and the imported file define a section (e.g. "on init"),
then the commands in the current file will be executed first, and then
the ones from the imported file(s).
The current implementation did not do that. It processed the import
directive inline, and thus the imported (i.e. dependent) files would
appear first in the command lists for the sections. This created
unintended side effects and the solution would have been to try and
put the import lines somewhere in the middle of the init file. This
would be difficult to notice and hard to extract the dependencies.
To solve this, we add the imports to a list for each file being parsed
and process the list after finishing parsing the file. This provides
predictable order for imports and provides a logical flow from the
user perspective: the currently parsed file gets to run its commands
before the files being imported.
Change-Id: I06dc35ff286314060e16b18923683cd2787269de
Signed-off-by: Dima Zavin <dima@android.com>
