Standard Android systems have a separate userdata partition that holds everything besides the equivalents of /boot/ (boot - more of a boot image in a firmware-dependent format than a real "partition", even though it's implemented as such) and a minimal, read-only /usr/, /bin/, /sbin/ (system). Everything else, not just /home/ is in the userdata partition; and the system must be able to (1) deal with a wiped userdata while preserving some kind of basic functionality, and (2) prompt for a password in case userdata is encrypted. It's a lot like running a "LiveCD with persistence", except that the space you get on the "LiveCD" part is hardware dependent, and can be very limited even on very recent Android phones.
So I was mostly thinking in the context of postmarketos, where we have a less-weird filesystem layout to work with and can assume that user data lives in the home directory and can be on its ownfilesystem.
That said: Yeah, Android+Linux is super weird if you're used to GNU+Linux:) And I'm pretty sure it would be more complicated, since I'm basically proposing that we protect data but not code; I think you'd need to protect /data at a minimum, maybe more (I forget where Android sticks the "internal storage" directory). That said, I think you could do it on Android.
Ah, sorry, no I actually meant the home directory in the case of postmarketos, although I wouldn't mind extending the concept to Android. It seems like you can get 90% of the benefit with 10% of the difficulty if you have an unencrypted OS but mount your home (well "user data") from an encrypted filesystem. Heck, I can't think of any reason that on a normal unix-like[0] you couldn't mount your whole home directory with encfs or something after login. This doesn't protect you from evil maid attacks, but for common phone threat models (theft, mostly) this is still a win.
[0] I was going to say GNU/Linux system, but pmos is based on Alpine which isn't really GNU so much as Busybox/Linux...
