Android: Add support for app bundles to catapult/devil |
||||||
Issue description
catapult/devil is used by the Chromium test scripts to manage devices during testing. This includes the ability to install / uninstall applications.
Currently, devil only supports the installation of regular Android Apk, and "Split APKs". This issue is created to add support for Android app bundles as well.
For the record, this requires using the bundletool [1] binary, which is distributed as a jar file, and used to do the following non-build tasks:
- Process an app bundle into an .apks archive (which is a zip file
containing a set of signed split APKs, and some configuration data
about the bundle, stored in an opaque protobuf-based format).
- Install the .apks archive to a connected device (this will select
the set of split APKs to install based on the device's
configuration).
- Probe a connected device to extract its "device spec", which is a
small JSON file describing the device's capabilities.
- Extract the split APKs from the .apks archive that correspond to
a given device spec file. These can then be sent manually to the
device with 'adb install-multiple'.
More information about this at [2]
Note that currently, the Chromium build system uses build/android/gyp/bundletool.py [3] to wrap the bundletool jar as an executable command. The .jar itself is distributed as a CIPD package under third_party/android_build_tools/bundletool/ [4]
For the record, the apk_operations.py script has been modified to call bundletool.py directly, instead of relying on devil [5]. The reason for this was lack of proper InstallBundle() in ApkHelper (or whatever other devil class that could help).
This entry is to track the issue and discuss possible implementation details.
[1] https://github.com/google/bundletool
[2] https://developer.android.com/guide/app-bundle/test
[3] https://cs.chromium.org/chromium/src/build/android/gyp/bundletool.py?q=bundletool.py&sq=package:chromium&dr
[4] https://cs.chromium.org/chromium/src/third_party/android_build_tools/bundletool/README.chromium?q=android_build_tools/bundletool/&sq=package:chromium&dr
[5] https://cs.chromium.org/chromium/src/build/android/apk_operations.py?dr&q=_InstallBundle&sq=package:chromium&g=0&l=115
PS: Filing here for lack of better location. Feel free to suggest another bug tracker.
,
Aug 7
,
Aug 7
#1, the proper process is to use binary-dependencies. I have written a convenient script for uploading Telemetry's binaries in https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/bin/update_telemetry_dependency It would be great if someone can generalize that script above to all binaries case
,
Aug 7
Thanks for the pointer, looking into this. Quick question: why is devil_dependencies.json using a platform name like "linux2_x86_64" which is not listed in binary_manager.py:SUPPORTED_DEP_PLATFORMS (which only uses 'linux_x86_64'). Trying to understand the history here...
,
Aug 7
THe binary_manager.py in Telemetry is not the same as binary_manager.py in dependency_manager/.. This is the case of duplicate naming + we don't enforce a set of standard platforms in dependency_manager/ which causes confusion :-(
,
Aug 7
Yes, I've seen that (actually, there is no binary_manager.py in dependency_manager/, but there is one in common/py_utils/py_utils/, and its unit-test also uses linux_x86_64, not linux2_x86_64). I'm just trying to avoid adding even more confusion to the situation. For now it looks like only devil uses linux2_x86_64 instead of linux_x86_64, and I don't see any good reason. I can either go with it, or "simplify" by changing all the linux2_ stuff into linux_ instead. Would that create problems?
,
Aug 7
Digging into it a little more, it looks like 'linux2' is used in several places to identify the Linux platform, including third-party dependencies. And this seems to be due to the value of the Python sys.platform value (which is now hard-coded to 'linux2' for historical reasons). It looks like I should be able to use dependency_manager/bin/update after updating devil_dependencies.json to add an entry to 'bundletool'. Since this is a prebuilt binary, is there a specific procedure to follow regarding LICENSE tracking or other stuff, to perform before upload to cloud storage? I plan to upload bundletool-all-0.5.0.jar from https://github.com/google/bundletool/releases/, with a download location of linux2_x86_64/ since devil only works for this platform apparently, and I don't know how easy if would be to introduce a 'common' platform. Is this ok for you?
,
Aug 8
This sound ok to me, though I am not owner of devil/ +Juan who is an owner of devil to answer David's question in #7
,
Aug 8
To be fair I would rather go the route of getting the binaries via CIPD (as that is supposed to be the new infra-supported way), and try to phase out the dependency manager. [Just like we are trying to move away from python modules in third_party, and get them via vpython instead.] Having said that I have no strong objections to the plan in #7 if that seems easier at the moment. +bpastene as the other devil owner in case you have any further thoughts.
,
Aug 8
+1 to what juan said. CIPD is the preferred method of downloading prebuilts/binaries. But we shouldn't block adding a new devil_dependency on converting everything to CIPD. So adding that jar sgtm
,
Sep 3
Back from vacation. Sorry for the delay. Thanks for confirming that I can do this. However, are there any issues regarding LICENSE distribution before uploading to cloud storage? Otherwise, I'll add a README.chromium file similar to the one used for Chromium third_party, somewhere...
,
Dec 21
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by digit@google.com
, Aug 6