Fixes #445 - Ship Fenix x86_64 builds

[st3fan]

This patch add support for building x86_64 builds. This is an experiment and I would like to get this working and tested on this PR branch first. This has low priority but ideally starts working before the end of July because of a Google Play Store deadline regarding 64-bit builds.

[boek]

Looks like the builds aren’t happy with it though

[st3fan]

@boek sorry i should have marked this as Do Not Merge or WIP - This has no priority, just something I'd like to get going.

[ghost]

Askin for help from @mozilla-mobile/releng - TaskCluster tells me

HTTP 424 Artifact "public/actions.json" not found at "/opt/fenix/actions.json"

And does not show any more details for these builds. Did I break things completely with my changes or is there something else going on?

[JohanLorenzo]

@st3fan hi! This Taskcluster error is some red herring[1]. In order to see the real error:

1. Copy the "Task Group ID" to the "Task ID" field and click on "Inspect"
2. Access the logs of the task.

In this case, it's a gradle error: No such property: geckoview_beta_x86 for class: Gecko

https://tools.taskcluster.net/groups/W7lE52rJSfaSQRSJNBeQvQ/tasks/W7lE52rJSfaSQRSJNBeQvQ/runs/0/logs/public%2Flogs%2Flive_backing.log#L392

[1] It shows up because the Taskcluster WebUI looks into this artifact to enable/disable commands under the "Actions" drop down. I've seen it for long, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1554599 to track this.

[pocmo]

This will at least need an update here too:
https://github.com/mozilla-mobile/fenix/blob/master/app/build.gradle#L136-L140
.. to generate unique version codes (x86_64 > x86 > arm64 > arm)

[ghost]

This now produces x86_64 APKs. @JohanLorenzo or @mitchhentges can you take a peek at the suggestions that @pocmo made in the previous comment? I am not sure what to do with the version code.

Right now x86 and x86_64 are treated the same way (if (variant.flavorName.contains("x86"))) and follow the same logic. Do we need x86_64 builds to have a different code?

The comment above that code says:

Our x86 builds need a higher version code to avoid installing ARM builds on an x86 device with ARM compatibility mode.

Without changes that still happens for x86_64. Or does x86_64 need special treatment?

[pocmo]

Without changes that still happens for x86_64. Or does x86_64 need special treatment?

They still need to be unique for every APK. And since the x86 AND x86_64 build can be installed on 64 bit x86 devices we would want to use a higher version code for the 64 bit build so that those devices get that build.

TL;DR: Adding a case that does +3 for x86_64 should be enough here.

[ghost]

I am just not having a lot of luck ...

> Task :architecture:compileDebugKotlin
Could not perform incremental compilation: Could not connect to Kotlin compile daemon
Could not connect to kotlin daemon. Using fallback strategy.

OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000b2150000, 82509824, 0) failed; error='Cannot allocate memory' (errno=12)

> Task :architecture:compileDebugKotlin FAILED
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 82509824 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /opt/fenix/hs_err_pid338.log

FAILURE: Build failed with an exception.

I'll run this again - but running out of memory is not something I've seen before.

[ghost]

@mitchhentges i see you editing in the decision_task.py too - do these changes still make sense? For example I see that I don't have to specify the architectures manually anymore - will it just discover by itself what flavors we have now?

[mitchhentges]

Looks great, yeah - it'll automatically detect all build types now for release

[ghost]

@mitchhentges great - lets see if the last small changes result in a green build and then we can land it I hope.