## Revisiting the Android, UserLAnd app.

One of the facts which I had reported some time ago was, that a handy, easy-to-use Android app exists, which is called ‘UserLAnd‘, and, that I had installed it on my Google Pixel C Tablet. As the tooltip suggests, this is an Android app that will allow people to install a basic Linux system, without requiring ‘root’. Therefore, it mounts the apparent, local Linux file system with ‘proot’ – which is similar in how it works to ‘chroot’, except that ‘proot’ does not require root by the host system to set up – and any attempts to obtain root within this Linux system really fail to change the userid, of the app that the files belong to, or of the processes running. Yet, becoming root within this sandboxed version of Linux will convince Linux, for the purpose of installing or removing packages via ‘apt-get’.

In the meantime, I have uninstalled the ‘UserLAnd’ Linux guest system from my Pixel C Tablet, in order to free up storage. But, I have set up something like this again, on my Samsung Galaxy Tab S6 Tablet, which has 256GB of internal storage. Therefore, I have a few observations to add, about how this app runs under Android 10.

Through no fault of the developer of this Android app, the user is more restricted in what he can run, because Android 10 places new restrictions on regular processes. Specifically, none of the major LISP Interpreters that were designed to run under Debian 10 / Buster will run. (:1) What the Linux developers did was, to make the garbage collection of their LISP Interpreters more aggressive, through a strategy that changes the memory protection bits of memory-maps, to read-only if they belong to the state of the machine, and then, ~to try deleting as much of the bytecode as can still be deleted~. Pardon me, if my oversimplification gets some of it wrong.

Well, Android 10 no longer allows regular apps to change the protected memory state of any pages of RAM, for which reason none of the affected LISP Interpreters will run. And for that reason, neither “Maxima” nor anything that depends on Maxima can be made to run.

Yet, certain other Linux applications, notably “LibreOffice” and “Inkscape”, run just fine… So does “GIMP”…

Also, the way in which files can be shared between the  Android Host and the Linux Guest System has been changed, as the following two screen-shots show:

Here, the file ‘Text-File.txt’ has been shared between Android and Linux. Larger files can also be shared in the same way, and the folder bookmarked under Linux. (:2)

In many ways, the Linux applications behave as described before, with the unfortunate exceptions I just named, and I intend to keep using this app.

Technically, a Host app that just sandboxes a Guest Application in this way, does not count as a Virtual Machine. A real VM allows processes to obtain root within the Guest System, without endangering the Host System. Also, ‘a real VM’ provides binary emulation, that makes no specific assumptions about the Guest System, other than, usually, what CPU is being used. Emulation that includes non-native CPU emulation is still a somewhat special type of emulation.

Therefore, the ability of Debian 10 / Buster to run under ‘UserLAnd’ depends, in this case, on the Linux package maintainers having cross-compiled the packages, to run on an ‘ARM-64′ CPU…

(Updated 9/13/2020, 21h30… )

## Another possible reason, why my Google Pixel C might have started crashing.

One of the facts which I posted about recently was, that My Google Pixel C Tablet had started crashing, roughly every one or two months. Because I haven’t really installed any new software on it, and because the most recent System Update took place sometime in mid-2019, I had assumed that the recent malfunctions could be due to some sort of hardware problem.

The fact that this tablet, which I only bought in 2017, was starting to become unstable, was partially also, why I have recently acquired a Samsung Galaxy Tab S6 tablet, as an eventual replacement.

But, there is in fact another possible explanation, for the crashes of the Pixel C. Until 2019, that tablet had received System Updates roughly once every month. It might just be that, due to many memory leaks, that tablet really needs to be rebooted once per month, and if nothing else, System Updates also resulted in soft reboots. The failure to perform any soft reboots, may be what’s leading to hard reboots. Only, hard reboots are dangerous, because too many of them can lead to file system corruption.

In that regard, I’m hoping that the new Tab S6, which has Android 10 installed, will offer a possible preventive measure, in the fact that it can be scheduled in advance, to reboot automatically, let’s say once per week. If that feature works out as expected, then the tablet in question may indeed last longer than the Pixel C did.

Really, I think it strange, that an Android tablet would crash – or hard-boot – because it was not soft-booted for more than a month. After all, my phones, also being Android devices, have usually been able to run for more than 2 months, without requiring any reboots, and when those finally do receive a soft-boot, it’s part of their System Update.

Dirk

## An observation about the new Chrome OS Smart-Lock and Instant Tethering features.

I own a Samsung Galaxy S9 smart-phone, and an Asus Flip C213 Chromebook. And, two relatively new features which Google rolled out are:

• Smart-Lock: The ability to unlock the Chromebook, using the presence of the phone, and
• Instant Tethering: It has always been possible to activate the Mobile Hot-Spot feature of the phone, assuming that a user has a plan that includes tethering, and then to connect the Chromebook (or other device) to it, in the form of a mobile, Wi-Fi Access Point. But, with Instant Tethering, the availability of the phone as a tether is supposed to be more quickly visible from the Chromebook, and theoretically, accessible with a single click.

What some people have reported is, that this feature does not always work 100%, even though the procedure was followed, which my readers can find in many other places on the Web, to set up the feature. I recently experienced as well that, on my first try, these two features were not working at all, when the Chrome OS version on my Chromebook was ’80.x’. Yet, even during the interval of my trials, an update to the Chrome OS version had presented itself, to version ’81.y’. And since the update, the features seem to work 50% of the time.

There was an additional step which can be taken, but should not be 100% necessary in this case, and which I took, which is outlined in this article:

https://www.howtogeek.com/fyi/chrome-os-instant-tethering-comes-to-more-android-phones-heres-how-to-do-it/

I will explain below, Why I changed the flag under:

chrome://flags/#instant-tethering

From ‘Default’, to ‘Enabled’. A reboot was required…

One reason these features may still not work 100% for me, could be the possibility of the phone going into ‘Deep Sleep’…