provide android builds
We want to provide Android builds, but the endpoint we use (https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/blob/rewrite/example.yaml#L6) only provides downloads for desktop versions.
Solutions
httpdirfs
We could use httpdirfs (see https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/onionsproutsbot/-/issues/11) and use binaries as provided by https://dist.torproject.org, but it's a bit hard to distinguish which files are to be used, as, not only is there a "version mismatch" between the latest stable version of the desktop and the mobile edition, but there are also many different versions, some of which are suitable for daily usage, whereas some of them aren't. (As of the time of this writing, the example that shows this happens to be 11.0.8, https://dist.torproject.org/torbrowser/11.0.8/ with the latest version being 11.0.10. The former version's directory only contains Android builds, whereas none of the more latest, stable versions provide Android builds.)
The bot having to decide which version is good based on parameters that may no longer exist in the future (e.g. someone could remove all Android builds ending in *androidTest.apk
, because "why not, what could possibly go wrong with this" is most likely a bad idea, and the maintenance burden would be higher than desired. This bot is meant to be robust, just running in the background and doing its job without causing problems every now and then.
F-Droid
We could use an F-Droid endpoint that provides builds (right now, the Guardian Project does so, and if the work is made to support obtaining files from their frontend, this can be easily switched to Tor's later on). This is by far the most realistic approach if other teams are not able to work on this, and F-Droid does provide APIs that could help. My recent efforts to make different parts of the program modular would help with getting something like this done. They have APIs as well: https://f-droid.org/en/docs/All_our_APIs/
However, I am concerned that the end result would turn out to be more fragile than it should be (such as telling apart the correct versions to be included), and a big refactoring session would still turn out to be required.
Website scraping
This website providing a list of downloads for the browser is manually updated (I think I recall @gaba telling me this): https://www.torproject.org/download/#android
We could hypothetically just scrape the website and just get the downloads and be done with this. However, again, this bot should just sit back, quietly, doing its job and not breaking over the smallest changes, such as a website redesign. In conclusion, no.
Tor Endpoint
To obtain a list of downloads for the desktop version, we currently use the following API endpoint: https://aus1.torproject.org/torbrowser/update_3/release/downloads.json
It would be pretty great if the project provided an endpoint for Android builds as well, especially because that would mean that a single "point of contact" would be telling my bot, as well as other projects that utilize the aforementioned endpoint, what to do, instead of my own bot scrambling to figure out what to do with a volatile set of data like that. However, with an F-Droid repository being supposedly around the corner, such a feature may be realistically way too much effort that I would be "outsourcing" to other people. However, something like that could also be useful for things such as providing lists of downloads through the website quickly. But that's neither my field or my fight.