Sometimes it crashes just running regular apt-get upgrade if it has too many packages to update, or takes too long. Switching away from the app can also mean it crashes.
Nice idea, nowhere near ready for anything but playing.
This was the issue I had doing anything interesting on Android in the past. It just randomly kills things so you can't do much more serious stuff than web browsing/social media on it.
I suppose normal GNU/Linux might have this issue as well if you run an OS with lots of background services that randomly consume large amounts of RAM or if your desktop environment does. I don't so outside of kind of insane environments like raspberry pi zeros or weird situations on servers I don't typically run into this. (and no. It's not 2010, phones are normal PCs not a weird embedded environment.)
Android app scheduling is different than what not-Android Linux does. oomkiller might kill stuff in high memory pressure situations, but Android does a bunch of dynamic loading and unloading all the time.
Your PC is built on a standardized architecture, your mobile device is its own bespoke SoC and requires unique, and often proprietary, methods just to boot and discover components.
It's the reason you can use any amd64 ISO to boot Linux on your PC, but each individual embedded device needs its own special image that is custom to that board, and often a custom Linux fork.
> just running regular apt-get upgrade if it has too many packages to update, or takes too long
That's really interesting! How's it handle nala[0]? I ask because it parallelizes apt. So if it crashes fast then might be a good hint that it is overloaded but if it is more successful could be a timeout?
Also... I mean nala is also a much better experience than apt...
I keep advocating that all these are kind of band aids, the right approach is to do the CLI as many non-UNIX OSes have done it, not by keeping VT100 hardware alive virtually.
In Android's case, a Java or Kotlin written Terminal app, exposing CLI capabilities, taking advantage of Android's APIs.
Even assuming the Terminal app works great, it is still only usable for playing, unless I am able to plug a keyboard, mouse and external monitor to a phone, and I have used both DEX and Windows Continuum in the past.
They are also working on a more full-fledged desktop mode in Android 16 QPR 1. Obviously, you can also plug a keyboard, phone, and external monitor. Pixel 8 and 9 support DP-Alt.
I am not sure why VT100 emulation is relevant in this context. Removing it will break a lot of existing Unix/Linux terminal applications and the point of this emulator is to bring the wealth of existing applications (as well as X11/Wayland applications) to Android.
Which naturally requires being a Pixel phone, and not something that works across the ecosystem.
Exactly because we should stop dragging UNIX all over place, and embrace new computing models, the world already has enough UNIX clones always redoing the same stuff over and over again, as if Lion's book had been published last week.
Same thing. Google owns both Android and the Linux Terminal app. Some combination of Google's OS and Google's app causes the app to crash or be crashed in the background. That's something that Google needs to fix regardless of where the bug lies.
Not if it's not crashing at all and is just a fundamental difference between Android's memory management and what the Debian guest is expecting (which is no RAM management at all)
OOM is only triggered when you actually run out of virtual memory. With modern phones that shouldn't normally happen unless you're doing something silly like compiling a web browser.
No, it's just Android working the way it was designed. Long running server or VM-esque apps are incompatible with Android's ideal process management and scheduling.
Apps are meant to be started and destroyed dynamically when the user does something else, their phone is idle for a long time, battery life is low, etc. If something is in the background it's fair game to kill.
Yeah, Google has control of the OS and can easily choose to fix the issue.
It's just an issue that plagued the last 15 years of attempts at getting Linux running in VMs/containers/etc on Android, and that's the reason it's an issue.
Developers might be able to work around the limitation by building dynamic suspending and restoring of VM state into their Linux launcher and try to make it play nice with Android.
Nice idea, nowhere near ready for anything but playing.