@BlockMechanic can you address my comments from the previous PR. Mainly basing this off the work that is already being done in #16110, rather than duplicating the changes.

These depends deal specifically with building QT for android as is. For the necessary changes to build the QML version, i'll push those later

@fanquake sorry, i am still getting used to using git and performing advanced actions like fethcing someone else's branch , and pushing changes here...hence the mess up i mentioned. I managed to get @icota's branch for #16110 but could not get it to cooperate properly on my end so i could push here.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17165 (Remove BIP70 support by fanquake)
• #17008 (build: bump libevent to 2.1.11 in depends by stefanwouldgo)
• #16110 (depends: Add Android NDK support by icota)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Mainly basing this off the work that is already being done in #16110, rather than duplicating the changes.

Good point. I think it would be good if the people working on bitcoin core on Android (@greenaddress, @BlockMechanic, @icota), would start working together instead of besides each other. It's not clear to me how the different changes relate to each other. Maybe we need an Android maintainer at some point. This worked for Windows/MSVC pretty well.

@laanwj I think the difference is that @BlockMechanic is trying to support 32-bit ARM and x86 as well. Like I commented in #16916 I don't personally see much value and don't have the devices to test this. But changes on top of #16110 are very welcome.

I'm working on a "packaging" PR (to produce an APK) to complement this. It is all very conceptual at this stage but if everything goes to plan and the PRs come together nicely (UI + reproducible build/package) I'd like to volunteer as the Android maintainer. But let's give it some time.

Yes my point is mainly that, for example, both PRs are bringing in a arc4random_addrandom patch for libevent, so it'd make sense for this PR be based #16110 (opened first, I prefer the patch naming there as well), rather than them being worked on in parallel.

This is now completed in #16110