author Greyson Gilbert <greyson.gilbert.oss@gmail.com>
Tue, 30 Jul 2019 23:32:29 +0000
changeset 549189 6019fc32fbf36e44a00248aa12f94c6f111a9213
parent 545808 c3a73a0bfbacfbe3b6cd776ae441cda296e41068
child 550345 fb0ae6ca73228b4a2d0b80c1ce5ab5ab337d0dd6
permissions -rw-r--r--
Bug 1564293 - Allow efficient slicewise upload of 3D textures r=jgilbert Before this patch any partial upload to a texture would incur a zeroing of the texture first to prevent leakage of information. The texture now tracks, for each image not fully initialized, which z-slices have been initialized, and only zeroes the rest of the slices when the texture is used. Differential Revision: https://phabricator.services.mozilla.com/D37843

APK publication


The push-apk task is in charge of uploading and publishing Android APKs onto Google Play store.

Push it all to Google Play

Before any request is made to Google Play, the push-apk task sanity checks the data passed over:

1. APKs are signed with the correct certificates. This may not sound extremely important because Google Play is vigilant about APK signatures and will refuse any APK for which the signature is not valid. However, it is safer to bail out before any outbound traffic is done to Google Play. Besides, with this check, Google acts as a second factor instead of being the only actor accountable for signatures.
2. All given APKs have matching data (version numbers, package names, etc.)
3. No required processor architecture is missing, in order to upload them all in the same request. We have to publish them at the same time because some Android devices support several architectures. We have already had one big crash on these devices because an x86 APK was overseeded by its “brother in ARM”.
4. APKs are multilocales

Then it uploads the APKs fetched in the previous task. Like said above, Google Play performs some additional checks on their end. For instance:
* they ensure the APK buildIds (called "version code") are higher than the last ones they have on file.
* they check whether the APKs are zipaligned (meaning, the APK archive has been optimized).
Google Play errors are reported back.

These checks and actions are done in several components. Here's how they interact:

.. image:: pushapk.svg

1. The “decision task” creates a task for pushapk_scriptworker
2/3. Scriptworker polls for pending tasks and check their scopes.
4. It downloads APKs via Chain of Trust. Scriptworker checks if the upstream tasks were altered.
5. Scriptworker defers valid tasks to pushapkscript. The latter validates APKs signatures, makes sure every APK architecture is present.
6. Pushapkscript calls MozApkPublisher with credentials and on-disk locations of APKs.
6/7. MozApkPublisher sanity checks the APKs.
8. MozApkPublisher opens the Google play credentials.
9. MozApkPublisher publishes APKs, listings and “what’s new”

For more information about the context, please see this `blog post`_.

..  _l10n website: https://l10n.mozilla-community.org/stores_l10n/
.. _pushapkscript: https://github.com/mozilla-releng/pushapkscript
.. _MozApkPublisher: https://github.com/mozilla-releng/mozapkpublisher
.. _blog post: https://johanlorenzo.github.io/blog/2017/06/07/part-2-how-mozilla-publishes-apks-onto-google-play-store-in-a-reasonably-secure-and-automated-way.html