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.
They presumably don't publish apps that use exploits to help the user gain root without unlocking the bootloader and wiping the data partition.
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.
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.
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.)
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).
I'm with you, but we'll always have AOSP. And the cellphone market is now segmented enough that we'll probably also always have rootable phones.
Over securing systems seems to be the modern trend, and mercy, it's such suffocating paternalism.
We have incredible phones and Android/Google just keeps making them less and less capable.
I'm sure that being an app store owner exposes you to the absolute worst just most constant stream of really really awful people doing the worst things, like, forever & ever.
There are some warped incentives too, for sure. But I do think Occam's razor explains why app stores get to be worse & worse & worse: because they are responding to horrors.
I'd love to see some better mechanisms for trust emerge. Software as it is is basically unobservable. You grant or don't grant some permissions & otherwise have no idea what's actually happening. So app stores are the only arbiters of trust.
In addition to having ridiculous computing power and storage capabilities, they carry microphones, cameras, WiFi, Bluetooth, NFC, lidar, radar...
If you can grasp not just the power of the device but the scale of its reach the only responsible and ethical action is to security harden it every chance you get as much as you can.
0: https://www.zippia.com/advice/us-smartphone-industry-statist...
But if you _do_ need a keyboard... it's android and it perfectly supports USB or Bluetooth input devices including mice, keyboards, etc. If you have a Samsung or some other devices you can even get a nice HDMI output to a monitor and desktop experience out of the box. It's really like a little laptop in your pocket at all times.
And if you need a GUI Termux runs X11, vnc, etc and GUI apps just fine. Just download a X11 server or vnc app from the play store (there are tons) and you're good to go.
And even if that sounds uncomfortable there's still plenty of useful things you can do with minimal typing! For example... You could run Tailscale as a normal Android app, then use SSH forwarding in Termux to get a local port that goes to a web server on another computer in your tailnet, and browse to that locally on the phone using Fennec F-Droid (Firefox). All of that works just fine. If I leave one of my computers on and I'm in bed or away from home I can ssh in and run systemctl suspend. Wayland/X server locked up? You can use your magic sysrq keys of course, OR you can ssh in with termux and kill it, which doesn't depend on magic sysrq being enabled (or remembering how to get it on your keyboard.) You could also run yt-dlp to download some video or audio content from the internet; everyone hates the Reddit video player, so why not just get the MP4 out of it? Admittedly, there's a better solution here: you can get an app called Seal on F-Droid which is a pretty good yt-dlp frontend. But, the fact that you can easily do it in Termux using their package manager is testament to just how useful Termux is.
I honestly only want one thing; an SSH Agent implementation built into the app, so I can import SSH keys and not have to enter the passphrase constantly. Not a huge deal really, but having a built-in agent would be super convenient.
tergent is a ssh agent for termux that uses the Android keystore, meaning your private keys are kept in your phone's secure enclave for a bit of nice extra security.
I use termux daily, and you can stand up pretty much anything including a production grade PostgresDB. It's not a toy.
Even if you don't use the CLI part of Termux often, it's still an incredibly neat piece of hackery goodness. I once needed to text about 50 people and have it be from my real phone number. Rather than hack around with Twilio or AWS, I spent 5 minutes writing a ruby script to send the texts from Termux. If you aren't familiar yet with the API, it will take a little longer than 5 mins the first time. Once I had that script, I kept finding neat usecases for it. I sometimes still just text from the CLI because it's easier than using the built-in messages app depending on what I'm doing.
You can definitely get an amazing experience on Android without Termux, but Termux is like if Android were a really nice bicycle, Termux is a small powered motor you can bolt on somewhere to automate parts of your life.
Aside: I find Termux easier to use than Tasker. I'm a CLI native old man though, so don't take this as a knock against Tasker.
The original script I wrote was initially set up with youtube-dl, the most recent change was to yt-dlp. For a lot of little things, like to SSH/reboot my rpi, wget a link I want to archive/send, small python programs (and yt-dlp), the keyboard is perfectly adequate. I've even converted a couple of audio files to send to a friend on iOS, from opus to mp3 on the phone. Bash alias are really useful, and because the phone isn't also general use, they can be very specific.
Termux also makes the phone into a very powerful network diagnostics and pen testing tool. But even something as basic as ifconfig makes my phone feel as powerful as a computer. https://github.com/may215/awesome-termux-hacking
Chromebooks have the ability to install and run android apps. The lightweight environment afforded by Termux is perfect for them. I do use VIM with my chromebook. I know I can use crostini, and in the past I was running crouton, but I realized I can handle 99% of those things in termux, and I can use VSCODE dev for the remaining 1%. I appreciate how much more flexibility termux gives me.
Google has been quite clear since NDK was introduced in Android 2.0, that is only for games and native methods implementations.
By "protecting" users from security threats, they are pushing power users to daily drive a rooted device, which is a bigger security risk. I expect incomplete/broken file storage access from Apple devices, not Androids.
The thing I hate the most is that certain apps only store files in their respective android/data/ folder and delete that data on uninstall. These workarounds are the only way to backup that data.
https://www.reddit.com/r/Android/comments/j3zgmm/managing_fi...
While Android can provide such feel, GNU/Linux smartphones (Librem 5 and Pinephone) are such computers. And they do not depend on Google in any way. (I'm a happy owner of both.)
Can you install a completely different OS on your Android phone? AFAIK no, whereas on Pinephone you can choose among 15+ systems and on Librem 5 currently among 4 or more. What about installing a mainline kernel?
> lack of social media and messaging apps
You can use Waydroid for Android apps, or install one of a few Matrix and Mastodon clients. Telegram works, too. Also, Flatpak apps work natively.
> I personally don't have any problem depending on Google, I have a problem with things being locked away with no alternative
To me these sound like the same problem. Google is restricting your freedom, not someone else.
You could in 2012, not sure about in 2023:
https://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/
> What about installing a mainline kernel?
I think Sony were working on that for their Xperia devices:
https://developer.sony.com/develop/open-devices/guides/kerne...
If you want full freedom from google, GrapheneOS feels like the best de-googled solution. In some ways, PRoot is to android what waydroid is to linux, except PRoot is way more capable. Google free AOSP, like GrapheneOS exists so it's not fair to say it's the same problem. I appreciate having access to things like Kali NetHunter and value that over being able to install and run a mainline kernel on bare hardware. I don't see a difference in installing a completely different OS vs PRoot, because I am focused on the functionality. I wouldn't be able to tell you a meaningful difference in function between iperf3 running on a Librem phone vs native termux vs PRoot.
Here's someone that's installed Termux on waydroid, installed on manjaro installed in Termux on an android phone. https://www.reddit.com/r/termux/comments/y0kupg/termux_on_ma...
Have you tried NewPipe for that use case?
But Yt-dlp is still more powerful, it has extractors for way more sites. If I download a video, I usually care to archive it for a longer term, so I add things like subtitles and metadata. For opus files, I don't like the webm container, so I would end up installing ffmpeg for that anyway. I also make heavy use of the regular youtube app, I appreciate the interface. Although I haven't had the need, Termux + yt-dlp also allows using aria2c for downloading. And yt-dlp has also been useful in bandwidth starved situations, because the url and format flags are enough to get the video, it doesn't hang while waiting to download related/recommended video metadata.
I still remember the first time I successfully SSHed to something from my Handspring Treo 180 over GPRS data, and felt like I was living in some kind of cyberpunk future.
https://github.com/termux/termux-app/issues/2366