Initialization stubs for the Android megazord

[bendk]

I started with Jo's work in #6607 and added gradle code so that this actually compiles.

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

Branch builds: add [firefox-android: branch-name] to the PR title.

[mhammond]

This seems OK but I wonder if it is the correct approach longer term - eg, imagine a world where these components are in libxul for Android, whereas a different set of components are in libxul for desktop. In this scenario there's not really any such thing as a "megazord" which makes sense to own this. In that world I guess we'd end up with a component dedicated to this initialization and which targets one single "configuration". I'm wondering if we should just do that here?

[jo]

Can we have a Megazord for Desktop and one for Android? I think that's not too much code duplication, isn't it?

[bendk]

This seems OK but I wonder if it is the correct approach longer term - eg, imagine a world where these components are in libxul for Android, whereas a different set of components are in libxul for desktop. In this scenario there's not really any such thing as a "megazord" which makes sense to own this. In that world I guess we'd end up with a component dedicated to this initialization and which targets one single "configuration". I'm wondering if we should just do that here?

I figured in that world the megazords would be the configuration. They change from being the crate that builds the dylib to the libxul dependency that bundles the Rust components. I haven't thought this through deeply at all though, do you forsee any issues here?

[mhammond]

Can we have a Megazord for Desktop and one for Android? I think that's not too much code duplication, isn't it?

We should maybe try and move away from the term "megazord"? In practice, it just means "the library in which the components ship". For Android, megazords/full doesn't really have any code at all, in the same way that when these components are in libxul for desktop there's also no (runtime) code involved in that. Thus, there's no real scope for any code duplication here - other than possibly this new capability. (This ignores all the build related code though)

I figured in that world the megazords would be the configuration. They change from being the crate that builds the dylib to the libxul dependency that bundles the Rust components. I haven't thought this through deeply at all though, do you forsee any issues here?

I'm not quite sure tbh. In oak, the build environment is slightly different from how it's done in app-services. Specifically, each crate is built, then megazords/full is built into a stand-alone static-lib libmegazord.a, then there's a new moz.build which builds libmegazord.so, taking only libmegazord.a as input. This is kinda forced on us by the m-c build process and is how libxul is built.

So I guess that while this might work fine, there also seems a risk that it will not - that we will still want this new "megazord config" code in its own crate so it ends up in libmegazord.a - ie, that the process for building libmegazord.a might not know how to do this (it currently doesn't compile anything IIUC, just links). But maybe that new project could make it work - that does have "code", even though in-practice it is just "dummy" code to ensure the correct symbols are pulled in (eg, see this monstrosity)

To put it another way, conceptually this is great, I'm just uncertain how great it will actually be due to build requirements I don't fully understand.

TBH, I'm also not too bothered by this, because it just means we need to adjust things for m-c, which is going to be true for many things.

[mhammond]

another thing I don't understand and I'm not sure if we experimented with, but why did we choose to have many megazords, rather than a single megazord with features to select the components?

[bendk]

To put it another way, conceptually this is great, I'm just uncertain how great it will actually be due to build requirements I don't fully understand.

I think you're intuition might be right here and we should have have 2 crates: One is responsible for the configuration/initialization logic and the UniFFI bindings and the other is responsible for integrating with the build system. It took me a while to get this gradle code working, which seems like a signal that we might have similar problems is moz-central.

[jo]

init component: #6618