Error while building Android 12 for a signed image

[Salini Venate]

Hi,

I'm getting a build error while trying to generate the Android-12 signed image using sign_target_files_apks:

Build details: building Android S for x86_64 on Intel celadon platform

1) The make file calls sign_target_files_apks from build/tools/releasetools/sign_target_files_apks but the build fails with below import error:

[ 99% 131551/131570] Package release: out/target/product/caas/caas-sign-targetfile-eng.svenate.zip

FAILED: out/target/product/caas/caas-sign-targetfile-eng.svenate.zip

/bin/bash -c "build/tools/releasetools/sign_target_files_apks -o        -d device/intel/build/testkeys/cts-release-test         --key_mapping  build/target/product/security/networkstack=device/intel/build/testkeys/cts-release-test/networkstack     out/target/product/caas/obj/PACKAGING/target_files_intermediates/caas-target_files-eng.svenate.zip out/target/product/caas/caas-sign-targetfile-eng.svenate.zip"

Warning: releasetools script should be invoked as hermetic Python executable -- build and run `sign_target_files_apks` directly.

Traceback (most recent call last):

  File "build/tools/releasetools/sign_target_files_apks", line 160, in <module>

    import add_img_to_target_files

  File "/svenate/celadon_S/build/make/tools/releasetools/add_img_to_target_files.py", line 63, in <module>

    import ota_metadata_pb2

  File "/svenate/celadon_S/build/make/tools/releasetools/ota_metadata_pb2.py", line 7, in <module>

    from google.protobuf import descriptor as _descriptor

ImportError: No module named google.protobuf

[ 99% 131552/131570] Package: out/target/product/caas/caas-img-eng.svenate.zip

command used:

/bin/bash -c "build/tools/releasetools/sign_target_files_apks -o  -d device/intel/build/testkeys/cts-release-test --key_mapping  build/target/product/security/networkstack=device/intel/build/testkeys/cts-release-test/networkstack     out/target/product/caas/obj/PACKAGING/target_files_intermediates/caas-target_files-eng.svenate.zip out/target/product/caas/caas-sign-targetfile-eng.svenate.zip"

2)  If I point sign_target_files_apks to out/host/linux-x86/bin/sign_target_files_apks, the above step succeeds in bash terminal, but fails when executed as part of build  with the error that it is not able to get soong_zip binary.

 File "/svenate/S_staging/out/host/linux-x86/bin/sign_target_files_apks/apex_utils.py", line 519, in SignApex

apex_utils.ApexInfoError: Failed to get type for /svenate/S_staging/out/soong/.temp/apex-container-hTH_qc.apex:

Failed to run command '['apex_compression_tool', 'compress', '--apex_compression_tool_path', '/svenate/S_staging/out/host/linux-x86/bin:/svenate/S_staging/prebuilts/build-tools/path/linux-x86:/svenate/S_staging/out/.path', '--input', '/svenate/S_staging/out/soong/.temp/apex-container-Hr12d3.apex', '--output', '/svenate/S_staging/out/soong/.temp/apex-container-QMPqER.capex']' (exit code 1):

Traceback (most recent call last):

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/internal/stdlib/runpy.py", line 197, in _run_module_as_main

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/internal/stdlib/runpy.py", line 87, in _run_code

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/__main__.py", line 12, in <module>

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/internal/stdlib/runpy.py", line 197, in _run_module_as_main

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/internal/stdlib/runpy.py", line 87, in _run_code

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/apex_compression_tool.py", line 199, in <module>

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/apex_compression_tool.py", line 192, in main

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/apex_compression_tool.py", line 123, in RunCompress

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/apex_compression_tool.py", line 53, in RunCommand

  File "/svenate/S_staging/out/host/linux-x86/bin/apex_compression_tool/apex_compression_tool.py", line 44, in FindBinaryPath

Exception: Failed to find binary soong_zip in path /svenate/S_staging/out/host/linux-x86/bin:/svenate/S_staging/prebuilts/build-tools/path/linux-x86:/svenate/S_staging/out/.path

Running: /svenate/S_staging/out/host/linux-x86/bin/avbtool print_partition_digests --image /svenate/S_staging/out/soong/.temp/tmpljvgp43f/apex_payload.img

b': b45b0889c98dd3a62b78b22b56d01aa5a64cafe0a95d65beef8554c3c767d887'

3) However, on an incremental build the soong_zip gets installed in out/.path and the build succeeds.

Can someone help me understand why the soong_zip does not get installed in the out/.path in fresh build when building for a signed image?

Or please help point out where I'm wrong?

[Dan Willemsen]

The *-sign-targetfile-* rule doesn't appear to be in AOSP, so this looks like an issue in your custom make code. Switching to the built sign_target_files_apks is definitely a good start.

out/.path should not have a working soong_zip, though it may be present -- the intention is to limit the available $PATH tools used in the build exactly to prevent this sort of issue. For commands that aren't allowed, we return an error and log its usage. Check the config to see if someone has improperly added soong_zip to the allowlist in your fork.

Rules within the build should be depending and calling the actual paths instead (but that's not what releasetools is set up to do), or adjusting PATH for their command, like when we call add_img_to_target_files here. Make sure that there are dependencies to every tool used by the script if you use that mechanism though, or you can get flaky builds.

I'd also question why you're [re]signing output in the build itself. Based on the names in the command, it's to sign the targetfiles with a test key that isn't caught by the CTS test that verifies that you're not shipping with well-known keys. But signing automatically with insecure keys means you're no longer getting that protection. It would be a better idea to mark that as a known failure until you do the real testing on the release image (especially since in this case it'll also complain about you running an 'eng' build).

- Dan

--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/7e6a98bb-6b35-4105-a2a2-d902c2073c8an%40googlegroups.com.