To keep the discussion focused, here are a few assumptions I'm working under when evaluating the feasibility of running a node on a phone. While these assumptions may not be 100% accurate, they are meant to be true for a majority of the discussion.
Given we are fast approaching 1TB for all Bitcoin related data, I don't expect users to be running a phone with 1TB of storage. In the event they have access and can afford a phone with these resources, the recommended setup should instead be one of the platforms we already support, e.g., minipc or SBC running linux.
For an end user of Bitcoin who wants to run on Android, I assume they are also running a wallet either on the same device or networked as a data provider to another device (phone wallet, lightning wallet, electrum server, etc). While other use cases for running a node without a wallet may exist, I'd argue they are niche enough to ignore for this discussion.
While android can run on a variety of hardware, it seems primarily for smartphones and tablets, which we can bucket as having similar resource restraints (connectivity, battery, CPU, RAM, storage, etc). For bespoke hardware setups that are not a mobile environment, e.g., SBC's, I'd imagine most of these can also run linux.
One of the arguments for supporting Android as a build target is that many people only have access to an Android smartphone/tablet as a personal computer. For this user, I think we should also assume they do not also have access to desktop computer. Furthermore, I think we should be skeptical as to what sort of internet they have access to, meaning we cannot assume they have a dedicated home WiFi and are instead using a mix of public internet or metered cell connections. As an example, many phone users use "data free" connections around the world, where a provider is reverse billed for the data costs for certain apps, e.g., Facebook, WhatsApp. This raises questions of how feasible it is for a user to pay for the bandwidth to fully validate the blockchain + pay for the electricity and bandwidth of keeping the node always on and synced to tip.
When thinking of what a user needs in order to be fully validating, doing IBD on a mobile phone seems less interesting to me vs keeping up with the chaintip. Because Bitcoin Core uses assumevalid for the majority of historical blocks, I suspect the majority of the time spent is in validating the last few months of blocks, where assumevalid is not used. This means if the user does not keep the phone on at all times, it will likely not be able to keep up new blocks since every block after IBD is fully validated (scripts + signature checks).
This means a phone user will likely need to keep the phone at home, plugged in, and on a dedicated internet connection in order for this to be a useable node.
AssumeUTXO is one way in which a user can sync to chaintip from a snapshot , while fully validating genesis to snapshot height. This could help make the wallet more usable for the user right away, but does not address the issue of a mobile device keeping up. IIUC, assumeUTXO also does full validation without assumevalid during its background sync (although this may have changed, or could be changed). I'm not sure a mobile phone would be able to keep up with the chaintip while also fully validating from genesis, under the assumeUTXO model.
Furthermore, if an Android user only has access to a phone, this presents some challenges in my mind as to how the user is sourcing the AssumeUTXO snapshot and getting it on the phone.
For lower end phones (e.g., cheaper than a minipc/SBC setup), are the storage drives well suited for Bitcoin Core? Specifically, for phones with low RAM. The UTXO set is close to or at this point greater than 16GB, which means a node frequently needs to flush to disk / randomly read from disk in order to connect a new block to the chaintip. This historically has created problems for raspi's with older spinning disks/SD cards, as the node quickly chews through the storage and corrupts it. Are there any concerns here of bricking a users phone after a year or so of running Bitcoin Core. This is more a question from my side as I am largely unfamiliar with storage mediums of phones smartphones that would be cheaper than a SBC/minipc setup.
In running Bitcoin Core on a phone, I suspect many issues users will encounter will not be with the GUI App but more with the node itself, e.g., node not keeping up, phone storage getting corrupted, IBD stalled, and other specifics that might arise from running on a variety of hardware that we don't currently test for or build for in the project. These requests for support would necessarily be upstreamed to the Bitcoin Core project, increasing the maintaince and administrative burden. Troubleshooting/reproducing/proposing fixes would also need to come from the upstream project, which is why I remain skeptical that the maintaince burden involved is simply getting Bitcoin Core to cross compile for an additional architecture and is instead much, much more. Said differently, almost every other platform we currently support assumes a certain type of user and maintaining a release for a Mobile OS user introduces a whole new set of assumptions.
Good point, this is orthogonal to the node being pruned. I'm still generally skeptical of something like a microSD card in that writing blocks could still be a bottleneck, since as I understand it writes are much slower than SSDs/NVME drives. IIRC, IBD connects and then writes the blocks sequentially before proceeding to the next block (although this could be changed?). This is why I'm arguing hardware that supports adding better peripherals should be our recommended setup.
It seems they can also run linux binaries1, a platform we currently support, so I don't see this as a compelling argument for supporting a new platform in our release.
Footnotes
https://www.reddit.com/r/Bitcoin/comments/ycv9ce/running_bitcoin_core_full_node_on_a_99_chromebook/ ↩