## 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… )

## How to Add a Web-browser to GNURoot + XSDL.

In This earlier posting – out of several – I had explained, that I’ve installed the Android apps “GNURoot Debian” and “XSDL” to my old Samsung Galaxy Tab S (first generation). The purpose is, to install Linux software on that tablet, without requiring that I root it. This uses the Android variant of ‘chroot’, which is actually also called ‘proot’, and is quick and painless.

However, there are certain things which a ch-rooted Linux system cannot do. One of them is to start services to run in the background. Another is, to access hardware, as doing the latter would require access to the host’s ‘/dev’ folder, not the local, ch-root’s ‘/dev’ folder. Finally, because XSDL is acting as my X-server, when GNURoot’s guest-software tries to connect to one, there will be no hardware-acceleration, because this X-server is really just an Android app, and does not really correspond to a display device.

This last detail can be quite challenging, because in today’s world, even many Linux applications require, direct-rendering, and will not function properly, if left just to use X-server protocol, à la legacy-Unix. One such application is any serious Web-browser.

This does not result from any malfunction of either Android app, because it just follows from the logic, of what the apps are being asked to do.

But we’d like to have a Web-browser installed, and will find that “Firefox”, “Arora” etc., all fail over this issue. This initially leaves us in an untenable situation, because even if we were not to use our Linux guest-system for Web-browsing – because there is a ‘real’ Web-browser installed on the (Android) host-system – the happenstance can take place, by which a Web-document needs to be viewed anyway – let’s say, because we want to click on an HTML-file, that constitutes the online documentation for some Linux-application.

What can we do?

## An observation about UIDs under Android, and what that means for running Linux under Android.

In this earlier posting I had written, that I had installed Linux on my Android tablet, that being the Samsung Galaxy Tab S, First Generation, and that I had done so without rooting the tablet, and without using any kind of image-file that can act as a virtual drive, via a kernel loop-mount.

Simply using this arrangement makes something obvious to me, which I have already known.

Under Android, the userids which the kernel keeps for file-ownership are one userid per app. Hence, when we run Linux on it, all the processes really have the same userid, that being the userid of the app ‘GNURoot’ in my case. The ‘chown’ and ‘chmod’ commands have no effect. This is what a regular ‘ls -al’ command reveals:


total 100
drwxrwx---.  2 root 9997  4096 Sep 27 17:03 .
drwxrwx---. 25 root 9997  4096 Sep 26 15:27 ..
-rw-rw----.  1 root 9997     0 Sep 27 17:03 dir_listing.txt
-rw-rw----.  1 root 9997     8 Sep 26 03:07 test_1.aux
-rw-rw----.  1 root 9997  5625 Sep 26 08:28 test_1.fdb_latexmk
-rw-rw----.  1 root 9997  5473 Sep 26 03:07 test_1.fls
-rw-rw----.  1 root 9997 18213 Sep 26 03:07 test_1.log
-rw-rw----.  1 root 9997 38253 Sep 26 03:07 test_1.pdf
-rw-rw----.  1 root 9997  1467 Sep 26 03:07 test_1.synctex.gz
-rw-rw----.  1 root 9997   734 Sep 26 08:28 test_1.tex
-rw-rw----.  1 root 9997   734 Sep 26 03:07 test_1.tex~




(Edit 10/08/2017 :

Here, the Android O/S itself and its (Dalvik) bytecode interpreter / flash-compiler, run as root. )

I can use the ‘adduser’ command to create a userid, which only my fake-rooted Linux system sees, and doing so assigns a useless password, but aside from that, only helps Linux organize personal data into a defined home-folder. Even if I was to proceed to launch my desktop manager as (fake) user ‘root’, as the Android kernel sees things, all the resulting processes would run as belonging to the same userid, as when I run the desktop manager as my created userid, that real userid still belonging to the one app ‘GNURoot’.

One effect this does have, is that if I use ‘GVim’ to edit a file and save the changes, I get a warning, that my userid does not have write-permissions for that file. Yet afterward, the new version of the file has been saved. Also, data which that Linux system’s applications store, does get stored. This appears to result, because GVim only looks at the UID before displaying that message, while the GID would suggest I have write-permission.

But it can become a little bit more interesting, if I use some other, non-Linux app, to store a file in one of my Linux-subfolders, and then want to alter those files from within Linux. That other, Android, file-management app has its own userid. And then there is one reason why each Android app can read the data of the other:

Each userid belongs to one group-id as well as numerous others, determined by the Android host system, that was granted because we gave both apps the permission to read and write files personally belonging to the Android user.

But, we cannot change the permission bits ourselves, nor the ownership, because we don’t really have root.

(Updated 09/29/2017 : )