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… )
(As of 9/12/2020, 19h05: )
I suppose that astute readers may ask themselves, How then, “Maxima” was ported to Android, as an Android app? And the answer to that question lies in the fact that my slap-dash evaluation of UserLAnd states a half-truth. Really, ‘gcl’, ‘clisp’ and ‘
sbcl‘ are 2 major Linux LISP versions, that don’t run under UserLAnd. However, ‘ecl’, which stands for “Embeddable Common LISP”, will run just fine, as the screen-shot below shows:
It would seem that ‘ecl’ just doesn’t use the same garbage-collection technique, that the other 2 flavours of Common LISP use. Thus, the way in which LISP programs can ultimately be ported to Android 10, is that their LISP code, which could also be seen as ‘their source code’, can be loaded into an ‘ecl’ state and compiled, barring any compatibility issues that might arise, just because ‘ecl’ may lack some of the finer features that the other 3 LISP’s have, those being the major ones. Then, this state can still be exported as an executable, and, voilà!
However, once a LISP program / state has been compiled like that, a change can no longer be made by the user, to try running it with a different LISP version. The LISP version is baked-in like that.
(Update 9/12/2020, 22h45: )
What I have shown above was not the most recommended way, to share files between the Linux Guest System and the Android Host System, because, unless a user has a file-browser on the Android side, that can bookmark the folder in question, the approach could become unwieldy.
What UserLAnd offers is, a pair of added entries in the ~sidebar~ of ‘document provider views’. This is my name for a type of view which Android apps can offer the user (not the system file-browser), from which the user is allowed to open certain files and folders, but, through another app. That other app can in some cases include ‘UserLAnd’.
The reason I have shunned, trying the Document Provider View -approach to sharing files with the Linux Guest System, was a mistake made somewhere, in describing the feature. According to that mistake, UserLAnd needs to be running an active session, to offer that. In my case, this would mean that I’d have a UserLAnd session running with an LXDE VNC desktop, that I have a VNC Viewer instance running, and that I have some third app running, from which Android would be offering me the Document Provider View.
That would amount to too many Android apps running simultaneously, and so I didn’t bother to test it at first.
A fact which I’ve learned however is, that the UserLAnd session does not need to be active, in order for this app to offer itself as a document provider, as described. And so, I tried it out, by using the Android “Snapseed” app, to open the JPEG Image, which I had just shared to Linux, to open with “GIMP”. This is what it was like, opening the JPEG File as input to Snapseed. UserLAnd was not running a session at the time:
(Update 9/13/2020, 13h35: )
One of the facts which I’ve recently learned is that the statement I made above was not 100% correct. ‘ECL’ is a version of Common LISP, which cannot just be told ‘to dump its state, resulting in an executable file’ (Which is something that ‘GCL’ can be made to do.) But, ‘ECL’ still has the facility to compile its LISP. And there are essentially three points which I’ve observed, just in trying to custom-compile Maxima v5.44.0, to use ‘ECL’, natively, on the ARM-64 architecture, with Debian Buster:
- When told to compile LISP into an executable, ‘ECL’ essentially puts together a command-line, that uses the ‘gcc’ command, And
- When I try to compile Maxima v5.44.0, I obtain This exact error, And
- I do not yet know, whether this error is specific to Maxima and ‘ECL’, or, whether it would affect all the future attempts I make, to run large, automated builds, the exact parameters of which are hard for me to override. If so, it’s a bug that could spoil my eventual experience of custom-compiling other people’s software, natively, on that tablet.
(Update 9/13/2020, 19h10: )
I have been able to custom-compile the command-line version of Maxima, 5.44.0, by using the ‘sbcl’ version of Common LISP to do so. My previous text contained the error, that this was one of the LISP versions that don’t run. But in fact, SBCL is one of the LISP versions that do run.
Yet, just getting that to work has shown me, that the UserLAnd -type Linux Guest System is unsuitable for software development, if that software development is to take place with the GNU / Linux tool-chain. At one point, installing ‘g++-8′ resulted in
a broken C++ compiler, (according to CMake), even though ‘gcc’ v8.3.0-6 continued to work.
‘CMake’ also can’t be used.
So therefore, with that Linux Guest System, I’ll be limited to canned software for the most part. And, for similar reasons, I also can’t just custom-compile and install the ‘wxMaxima’ front-end to ‘Maxima’. I
have yet to try out ‘GNUPlot’, which I installed from the Linux package manager…
One of the ways in which UserLAnd does things differently from how ‘real Linux’ does them, is that UserLAnd overrides several libraries, with libraries that are supplied via Android, and which are mounted into the Guest System in a read-only way. These libraries sometimes fail to provide symbols, that the real Linux libraries do provide, but just because the overlaid libraries are linked to first. For this reason, when there is in fact the sort of linker error that I dealt with this afternoon, I cannot immediately tell, whether this is due to how Debian cross-compiled certain packages to run on an ARM CPU, or whether it’s because, the Android version of some library fails to implement something, that the Debian, cross-compiled version would implement.
This issue starts to become the more obvious, the more compiling anybody tries to do, in C++ or even C.
Granted, this setup gives maximum security to users, against the possibility that they could irretrievably lose their system, due to mistakes made with ‘root’ privileges. An erroneous attempt to change the Android-provided ‘assets’ just resets itself, the next time the user boots into Linux again. Or, the Android user can just wipe his UserLAnd Guest System and start a new one.
Also, development using languages that are not heavily dependent on a specific ABI, such as, using ‘interpreted languages like Python 3′, might still work. But even there, this would only work as long as the (Debian) Python bindings don’t depend too strongly on the C++ or C libraries…
(Update 9/13/2020, 20h00: )
After careful work, I think I have now restored some order to my libraries.
(Update 9/13/2020, 21h30: )
I was eventually able to quench my thirst for a graphical front-end to the custom-compiled version of ‘Maxima’. It turns out, that the packaged version of ‘wxMaxima’ can just be installed from the package manager, which also pulls in the non-functional, packaged ‘Maxima’. But, since I generally install my custom-compiled programs to ‘/usr/local/bin’, and since the packaged versions almost always install to ‘/usr/bin’, it’s rather easy and even automatic, for the packaged ‘wxMaxima’ to use ‘/usr/local/bin/maxima’, if that is present, while ignoring ‘/usr/bin/maxima’. And, if the GUI did not choose the back-end that I wanted it to choose, this can also be overridden in the Configuration Panel of ‘wxMaxima’. Therefore, the front-end that package maintainers built for me, works well with the custom-compiled back-end:
I guess that means, ‘GNUPlot’ works as well.