There is no distribution that does what you're looking for. All the ones recommended by others in this thread are just generic distributions that do nothing special to separate user applications and I have no idea why they saw fit to mention them at all.
The best recommendation here is Qubes but that's arguably not a distro but rather its own operating system that can then run some instances of distros inside of it with strong separation between those units.
The only thing that somewhat goes the direction you want is Flatpak but it's not anywhere close to Androids really quite solid app separation scheme.
The reality of it is that most Linux desktop apps are made with the assumption that they are permitted to access every resource the user has access to with no differentiation; your SSH or GPG private keys are in the same category as the app's config file.
Standard APIs to manage permissions in a more fine-grained manner are slowly being worked on (primarily by the flatpak community IME) but it's slow and mostly focused on container stuff which I'm not convinced is the way forward. There does not appear to be any strong effort towards creating a resource access control design that's anywhere near as good as Android's in any case though.
The closest thing we have is systemd hardening for system components but that's obviously not relevant for desktop apps. It's also (IMHO) inherently flawed due to using a blocklist approach rather than an allow-list one. It's also quite rigid in what resources it controls.
I'm not convinced any of the existing technologies we have right now is fit for a modern user-facing system.
Here's what I think we ought to have:
- A method to identify applications at runtime (e.g. to tell apart your browser from your terminal and your editor at runtime)
- A generic extensible way to declare resources to which access should be controlled within a single user context (i.e. some partition of your home filesystem or some device that your user generally has access to such as your camera)
- A user-configurable mapping between resources and applications; enforced by kernel-level generic mechanisms
No need for any containers here for any of this; they're a crutch for poor legacy distro design that relies on global state. I don't see a need for breaking the entire UNIX process model by unsharing all resources and then passing in some of them through by overly complex methods either.
Eventhough they're quite simple and effective, I'm not convinced UNIX users are a good primitive to use for application identification like Android does it because that implies user data file ownership needs to be managed by some separate component rather than the standard IO operations that any Linux apps ever uses for everything.
I think this should instead be achieved using cgroups instead which are the single most important invention in operating systems that you can actually use today since UNIX IMHO.
The missing parts are therefore a standard for resource declaration and a standard and mechanism to assign them to applications (identified via cgroup).
I haven't done much research into whether these exist or how they could me made to exist.