7 ms·

> Apps on Android have no access, or ability, to directly call kernel functions. That is nonsense.

gjsman-1000 2y ago
Technically, it's true, as far as I am aware. Android has low level functions which themselves then directly call Linux, but you are not allowed to make a direct Linux call. I could easily be completely wrong though.
- fluoridation 2y ago
  What do you imagine happens when you call fopen()? At some point there's a transition from user mode into kernel mode. What can the system do to prevent normal "app" code from making the transition but not "low level" code, when it's all user mode stuff running in the same process?
  - gjsman-1000 2y ago
    [flagged]
    - Jyaif 2y ago
      > Android's fopen() function is indeed an abstraction over the Linux fopen() system call Yikes, `fopen` is not a system call...
    - AdelaideSimone 2y ago
      What exactly is it you're "right" about? How do you think any libc wrapper or direct syscall works? Syscalls are filtered for security reasons on many platforms, including Android. I mean, a syscall is literally an API itself to get a kernel's internals to do something for you. What you're suggesting is, as someone else said, non-sensical. Phrased without invincible ignorance, it's equivalent to saying, "Android prevents you from creating a new OS kernel to supplant its own control over hardware access," which is true of basically any OS. How helpful or secure would it be if you could make 0 guarantees about how your hardware is used? You can do direct hardware access through drivers that are integrated/interfaced with the kernel somehow, but this still is not an entirely arbitrary access, and is still going through the kernel in a way.
- bri3d 2y ago
  In the Android-y part of Android, yes, they use ART, which is abstracted. But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code? It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example. As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
  - NotPractical 2y ago
    > you're allowed access to full Linux-land Yes, but there are strict SELinux policies forbidding you from accessing certain "dangerous" stuff like execve(), which may end up killing native terminal emulators like Termux (despite Android not forbidding dynamic code execution elsewhere, Play Store policies aside). https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/2155 https://github.com/termux/termux-app/issues/2155
    - bri3d 2y ago
      Sure, and this VM solution is the exact path forward for “install stuff in a box” solutions as Android move towards trying to enforce w^x, which is probably why they chose a full Linux VM as their demo app. Emulators and games and apps with embedded JIT will be harder to deal with.
- murderfs 2y ago
  You are completely wrong.

Technically, it's true, as far as I am aware. Android has low level functions which themselves then directly call Linux, but you are not allowed to make a direct Linux call. I could easily be completely wrong though.

fluoridation 2y ago
What do you imagine happens when you call fopen()? At some point there's a transition from user mode into kernel mode. What can the system do to prevent normal "app" code from making the transition but not "low level" code, when it's all user mode stuff running in the same process?
- gjsman-1000 2y ago
  [flagged]
  - Jyaif 2y ago
    > Android's fopen() function is indeed an abstraction over the Linux fopen() system call Yikes, `fopen` is not a system call...
  - AdelaideSimone 2y ago
    What exactly is it you're "right" about? How do you think any libc wrapper or direct syscall works? Syscalls are filtered for security reasons on many platforms, including Android. I mean, a syscall is literally an API itself to get a kernel's internals to do something for you. What you're suggesting is, as someone else said, non-sensical. Phrased without invincible ignorance, it's equivalent to saying, "Android prevents you from creating a new OS kernel to supplant its own control over hardware access," which is true of basically any OS. How helpful or secure would it be if you could make 0 guarantees about how your hardware is used? You can do direct hardware access through drivers that are integrated/interfaced with the kernel somehow, but this still is not an entirely arbitrary access, and is still going through the kernel in a way.
bri3d 2y ago
In the Android-y part of Android, yes, they use ART, which is abstracted. But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code? It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example. As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
- NotPractical 2y ago
  > you're allowed access to full Linux-land Yes, but there are strict SELinux policies forbidding you from accessing certain "dangerous" stuff like execve(), which may end up killing native terminal emulators like Termux (despite Android not forbidding dynamic code execution elsewhere, Play Store policies aside). https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/1072 https://github.com/termux/termux-app/issues/2155 https://github.com/termux/termux-app/issues/2155
  - bri3d 2y ago
    Sure, and this VM solution is the exact path forward for “install stuff in a box” solutions as Android move towards trying to enforce w^x, which is probably why they chose a full Linux VM as their demo app. Emulators and games and apps with embedded JIT will be harder to deal with.
murderfs 2y ago
You are completely wrong.