Include the hashtree in Q-launched modules.
For post-Q modules, we can avoid building the hashtree also in the
unbundled build case, since the device will regenerate the hashtree
locally. This CL simplifies the logic so that the build rules apply
regardless of the build being bundled or unbundled -- after all, bundled
build are only really valid for development purposes.
Fix: 147600151
Test: unit test;
m com.android.conscrypt and manual inspection of apexer invocation
(option no_hashtree not present)
m com.android.neuralnetworks and manual inspection of apexer invocation
(option no_hashtree present)
Change-Id: Ib4cc6149d3beac5df7e23a65a3b7ee6b0d68e395
diff --git a/apex/builder.go b/apex/builder.go
index 4a760b9..8e73ece 100644
--- a/apex/builder.go
+++ b/apex/builder.go
@@ -383,7 +383,7 @@
ctx.PropertyErrorf("test_only_no_hashtree", "not available")
return
}
- if (!ctx.Config().UnbundledBuild() && a.installable()) || a.testOnlyShouldSkipHashtreeGeneration() {
+ if !proptools.Bool(a.properties.Legacy_android10_support) || a.testOnlyShouldSkipHashtreeGeneration() {
// Apexes which are supposed to be installed in builtin dirs(/system, etc)
// don't need hashtree for activation. Therefore, by removing hashtree from
// apex bundle (filesystem image in it, to be specific), we can save storage.