can device-specific binaries ever be considered meaningfully reproducible?

[Fay Stegerman]

* kpcyrd <kpcyrd at archlinux.org> [2024-08-05 03:48]:
> On 8/5/24 2:41 AM, Fay Stegerman wrote:
> > I personally don't think these device-specific APKs can be considered
> > meaningfully reproducible even if building from source for a specific device
> > gives me the same APKs installed on that specific device.
> > 
> > Because the whole part about "allow[ing] multiple third parties to come to a
> > consensus on a “correct” result" breaks down completely when "correct" is
> > device-specific and not something everyone can agree on.
> > 
> > For example, I would not be able to rebuild and compare results with a friend as
> > -- unless we have (sufficiently) identical devices -- we would never get the
> > same bitwise identical artefacts.
> > 
> > I'm wondering what y'all think?
> 
> I know very little about android (especially about split APKs), but I think
> if "device specific" is sufficiently documented/specified it can be
> considered reproducible no problem.
> 
> It's just that there's now more permutations/artifacts that need to be
> reproduced instead of a canonical
> 
> Signal-Android-website-prod-universal-release-7.12.3.apk
> 
> I think it can be compared (somewhat) to how Debian has different .deb files
> for different CPUs.

Thanks!  I agree it's similar.  But there are a lot more permutations/artefacts
here than one .deb per CPU architecture (one .apk per CPU architecture is
already common).

Now you have a different APK (or actually several APKs that get combined when
installed) depending on a specific combination of at least CPU architecture,
installed locales, screen density, and android version [1].  As well as dynamic
features loaded on demand [2].

Debian still has canonical .deb files per CPU architecture.  Reaching consensus
on the "correct" .deb is still easy.  Though even then e.g. arm64 and amd64
users don't get the same .deb and thus can't really have any guarantees that
they are both running the same code (just that they are both running the
canonical code for their CPU architectures, generated from identical sources).

But here, when you install/update an app, Google Play generates the right
combination specifically for your device, based on its characteristics; and may
add additional components on-demand later.

Is it still theoretically possible to have this be reproducible?  Yes.  My worry
is that it is simply no longer *practical* with this many variables.

- Fay

[1] https://developer.android.com/tools/bundletool#device_specific_apks
[2] https://medium.com/googleplaydev/what-a-new-publishing-format-means-for-the-future-of-android-2e34981793a