> Have you considered hosting the APK on your own website? You would need to build your own update function, but it could be a periodic fetch of a version file,

> Have you considered hosting the APK on your own website? You would need to build your own update function, but it could be a periodic fetch of a version file, and if the version is newer, download the apk and when done prompt the user to upgrade, opening the (already downloaded) apk in the system installer if they agree. Apart from vending on F-Droid, this is what we do as our app is pretty much under perennial threat of a PlayStore ban. 1. We plonk the apk in a not us-east-1 Lightsail Object Store [0]. Smaller sized apks (if less than 25MB) can be instead stored in Workers KV, which comes with a generous free-tier. Or one can split larger apks (if less than 100MB) and join them in a single buffer in Workers before sending out. 2. Front it with Cloudflare Workers, and use their free-to-use Cache API [1] to avoid hitting the relatively expensive Lightsail endpoint often. 3. The app-update api-endpoint is also on Workers. Latest app version-code is stored in a Workers env-variable. The origin Lightsail path in a bucket is a hash(versioncode+salt). This setup costs less than $1/mo and we drive multiple TB traffic, with only ~5GB hitting Lightsail. Fly.io also has a neat CDN-esque solution for this [2], whilst GitHub's also a viable alternative [3] [0] https://lightsail.aws.amazon.com/ls/docs/en_us/articles/buckets-in-amazon-lightsail https://lightsail.aws.amazon.com/ls/docs/en_us/articles/buck... [1] https://developers.cloudflare.com/workers/runtime-apis/cache https://developers.cloudflare.com/workers/runtime-apis/cache [2] https://community.fly.io/t/first-look-static-asset-caching/ https://community.fly.io/t/first-look-static-asset-caching/ [3] https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository https://docs.github.com/en/repositories/releasing-projects-o...