Also make matching changes to applypatch modules which include
edify/expr.h.
Test: mmma bootable/recovery
Change-Id: Ia72be3caa010d7f56a70add2da345e631b306378
This reverts commit 26436d6d60 to re-land
"Move error_code.h into otautil.".
This way it stops requiring relative path ".." in LOCAL_C_INCLUDES
(uncrypt and edify). Soong doesn't accept non-local ".." in
"local_include_dirs".
This CL needs to land with device-specific module changes (e.g. adding
the dependency on libotautil).
Test: lunch aosp_{angler,bullhead,dragon,fugu,sailfish}-userdebug;
mmma bootable/recovery
Change-Id: If193241801af2dae73eccd31ce57cd2b81c9fd96
And move '#include "edify/expr.h"' into .cpp files. This breaks the
transitive dependency on libedify. Modules that include
"applypatch/applypatch.h" don't need to add libedify into their
dependency list, unless they really need anything from libedify.
Build libedify static library for host, which is needed by
libimgpatch.
Test: mmma bootable/recovery
Change-Id: Ibb53d322579fcbf593438d058d9bcee240625941
Use forward declartion to avoid pull in the module that contains
error_code.h (trying to move it into libotautil). Otherwise all the
modules that include "edify/expr.h" need to depend on the module that
exports error_code.h.
.cpp sources should include "error_code.h" explicitly to use the enums.
Test: lunch aosp_{angler,bullhead,dragon,fugu,sailfish}-userdebug;
mmma bootable/recovery
Change-Id: Ic82db2746c7deb866e8cdfb3c57e0b1ecc71c4dc
This way it stops requiring relative path ".." in LOCAL_C_INCLUDES
(uncrypt and edify). Soong doesn't accept non-local ".." in
"local_include_dirs".
Test: mmma bootable/recovery
Change-Id: Ia4649789cef2aaeb2785483660e9ea5a8b389c62
It used to be containing some unit tests for basic edify syntax, which
has been moved into recovery_component_test (commit
d770d2e7af).
The edify_parser host tool supports edify built-in functions only, but
doesn't recognize the ones defined in updater. This makes it much less
useful to do any real analyzing work.
Test: mmma bootable/recovery
Change-Id: I3c12f5402d2d6698e0ef5ac6c2e7804c0fbba78a
The earlier commit in 2dfc1a3898
unintentionally changed the behavior. It gives a different result when
looking up non-existent mount points (e.g. /cache on marlin).
The logic behind volume_for_path("/xyz") is unclear:
- It's fine to return non-null value if it's called by
ensure_path_mounted() before accessing that file "/xyz". (Just based
on the function name, we're not actually having this case.)
- It should return nullptr if the caller is interested in the existence
of that particular mount point "/xyz".
This CL renames the function to volume_for_mount_point(), which does an
exact match by querying the given mount point from libfs_mgr. The former
volume_for_path() has been moved down to function scope for serving
ensure_path_mounted() only.
Test: Build and boot into recovery on bullhead and marlin respectively.
'View recovery logs'.
Test: 'Mount /system'
Test: 'Apply update from ADB'
Change-Id: I1a16390f57540cae08a2b8f3d439d17886975217
And add the missing include of <string.h> (e.g. for strcmp(3)).
Minor update to the arg of fs_mgr_get_entry_for_mount_point(), which now
accepts std::string.
Test: mmma bootable/recovery
Change-Id: I9cb8c31fe71b5a053f4d84bf1aba00e96c02ed03
Tao Bao
Luke Song
Treehugger Robot
Chih-Hung Hsieh
Tianjie Xu