I really wish Android would properly enable containers like they've done for Chrome OS. It's silly we run little Linux machines and can't pop a fully isolated container shell on them!
https://www.xda-developers.com/android-13-dp1-google-pixel-6...
That just means no container-based virtualization, though. There's nothing stopping a sufficiently-powerful Android device from running a Linux virtual machine, presuming that the hypervisor is implemented as a regular Android application using regular Android-runtime APIs.
> ...then that process can escape the application's sandbox and do stuff it shouldn't be able to do given the permissions granted to the Android application.
Android's sandboxing is not limited to ART and has multiple layers [0]. Native apps cannot bypass sandboxing, I don't think.
[0] https://hernan.de/blog/tailoring-cve-2019-2215-to-achieve-ro...
Interesting; but I feel that their choice of a hypervisor-based design here supports my point of plain container-based isolation (or even containers + gVisor) being insufficient to achieve true sandboxing on Android.
> Android's sandboxing is not limited to ART and has multiple layers [0]. Native apps cannot bypass sandboxing, I don't think.
Yes, but when I say "sandboxing", I mean just the ART sandbox, not the other layers. I don't care whether you can get root / jailbreak the device. I (and presumably Google, in not publishing apps that do this in the Play Store) care about whether an application that, upon installation, doesn't request permission to e.g. read your contacts, can actually read your contacts. There are certain capabilities like that (not sure if "reading your contacts" is one of them, but you get the idea), that are only prevented from being accessed by ART, not by Linux ACLs. This is especially true when there's one level of permission that gets you access to a certain database file through an API, but then another level of permission that gets you access to certain special records in that database file through the same API. The lower level of permission is already granting you Linux filesystem ACLs to the database file; the only difference between the two permissions comes down to what ART will allow you to request through the higher-level API.
Which is one of the reasons why Termux has issues on modern Android versions.
https://github.com/termux/termux-packages/wiki/Termux-and-An...
This is not something Android does.
"Starting in Android 7.0, the system prevents apps from dynamically linking against non-NDK libraries, which may cause your app to crash. This change in behavior aims to create a consistent app experience across platform updates and different devices. Even though your code might not be linking against private libraries, it's possible that a third-party static library in your app could be doing so. Therefore, all developers should check to make sure that their apps do not crash on devices running Android 7.0. If your app uses native code, you should only be using public NDK APIs."
-- https://developer.android.com/about/versions/nougat/android-...
"Improving Stability with Private C/C++ Symbol Restrictions in Android N"
-- https://android-developers.googleblog.com/2016/06/improving-...
"Namespaces for Native Libraries"
-- https://source.android.com/docs/core/permissions/namespaces_...
The things you’ve linked are attempts to discourage people from depending on private implementation details. They are not a security boundary, nor are they really the kinds of APIs we’re talking about in this context. Since they run in your process there is no sandboxing or isolation involved here; you can call them if you really want to by looking them up manually. (Don’t do this.)
They presumably don't publish apps that use exploits to help the user gain root without unlocking the bootloader and wiping the data partition.
Androids built in app backup functions are woefully incomplete, and switching to a new phone recently I had to relogin to most apps and re-set up nearly everything, except for stuff like contacts and anything from google. At least some apps supported exporting settings to external files and allowed re-importing them.
When I do run into apps that are difficult to run, I make sure to give them 1-star reviews. I consider attempts to block rooted devices from running an app to be malware.
I don't think I knew it was on the Play store. It's a free download from the website, but paid on the Play store. I'd like to make a donation without giving Google a cut - the author deserves to get paid.
I get what you're trying to say, but perhaps you mean the ContextManager / ServiceManager, which isn't tied to ART at all, but Binder (Android's primary IPC mechanism), instead.
Re: Linux ACLs: Yes, those flaws existed, but don't think they do anymore (see also the blog I linked above).