A fact which I had lamented about, was that my Samsung Galaxy Tab S, First Generation – Android tablet – had essentially crashed. Its behavior had gotten so unstable as to make it unusable.
What this also did – given that I have a working Pixel C – was make the software / firmware -installation on the Tab S expendable, which meant that as soon as I was over the loss, I found myself willing to experiment with it.
So I did a factory reset, which made it stable again, at the expense of deleting all my user-data and separately-installed apps from Google Play. Essentially, the tablet had crashed while I was doing a routine update of apps, for which reason the FS corruption was limited to the ‘/sdcard’ partition, where user-installed apps are stored, as well as perhaps, to the ‘/data’ partition, where application data is stored. The factory reset empties those, and, because no system software update was taking place at the time of the crash, the ‘/system’ and ‘/boot’ partitions probably did not suffer from any corruption.
Then, I installed Linux on that tablet, using the Google Play store app named “GNURoot“, as well as using the Google Play store app named “XSDL“. When we install Linux on Android-capable hardware, we need to have a working Android system on that as well, because only the Android software can really provide the display drivers, and the I/O.
XSDL is an Android app which emulates a Linux X-server, which Linux sessions could connect to, as long as the Linux sessions can be persuaded not to try launching their own X-server instance, which their packages tend to depend on.
GNURoot is an app for Android 6+ that allows Debian / Jessie packages to be installed directly to the Android File System, and which runs those packages as though it was Linux. Remarkably, it does not require the device be rooted. It also uses the Android kernel. With the correct packages installed, it’s possible to get a proper desktop-session going between ‘GNURoot’ and ‘XSDL’. But the process is not user-friendly.
At first I had tried to install a system of ~400 packages, that provide ‘XFCE’, only to find that this desktop-manager could not connect to the ‘XSDL’, X-server, at least in any way I could get working. But then I tried uninstalling ‘GNURoot’, reinstalling ‘GNURoot’, and then installing the packages for ‘LXDE’, which is a lightweight, yet better desktop manager than the older XFCE would have been. This time, doing so required I patiently install ~600 packages.
Apparently, LXDE could be told to connect to an ‘XSDL’ instance quite well, and I obtained a working desktop-session. I also installed “GIMP” and “Blender”, which both ran fine – even on my Android tablet !
There was one caveat to using this configuration however, which is that
I absolutely needed to connect an external, Bluetooth mouse, as well as an external Keyboard. Apparently, the ability of ‘XSDL’ to provide virtual replacements for those, just wasn’t up to snuff.
(Updated 10/04/2017 : )
I have been able to get the mouse- and keyboard-emulation (of XSDL) to work. Yay!
There is a bit of a trick to understanding how the mouse-emulation is supposed to work. What some users might expect, is that when the mouse-pointer is being displayed someplace, we can just single-tap someplace else, effectively to end up left-clicking at the other location. With XSDL, things just work a bit differently.
When XSDL first establishes a session, its mouse-pointer is in the center of the screen. Next, when we tap anywhere on the screen, the mouse-pointer next jumps into the top-leftmost corner of the screen, and acts as if we had clicked there. Depending on what desktop manager we have installed, the default response to that could be entertaining. But what we must next do, in order to change the position of the mouse, is just drag our finger over any distance on the screen. Hence, when I was just repeatedly tapping different parts of the screen, this caused the mouse-pointer repeatedly to left-click the top-leftmost corner of the screen. After we drag the mouse-pointer where we want it, we may actually single-tap any part of the screen, to signal the left-click, wherever the mouse-pointer is just being displayed.
Further, because this means that we may take a long time just to position the mouse-pointer exactly where we want it, it next becomes important, not to change the default setting, on how to right-click. If we change the XSDL setting, so that to hold for several seconds signifies a right-click, then the amount of time we are taking just to position the pointer correctly, will often get registered as a right-click – in a wrong place. So, the default of having the second (middle) finger come down, to signify a right-click, is actually an optimal setting, since it seldom results in false right-clicks.
Also, the virtual keyboard can in fact be brought up, when we hit the Android back-button (if we have one), or otherwise, to swipe up from the bottom of the screen. This works all the better, if our keyboard is the Hacker’s Keyboard, which has all the ASCII-characters most legacy computing wants, and which I had installed anyway, because anybody who is serious about computing, would install Hacker’s Keyboard.
The fact that we can install Debian binaries relies on the fact that the official repositories make them available for numerous CPUs, not just x86 32-bit or 64-bit, but also for the ARM CPUs, that Android-capable hardware uses.
Further, I do not have desktop-screen-capture software installed on that Linux subsystem yet,
for which reason I cannot yet provide screen-shots of GIMP or Blender…
The fact just occurred to me, that because this Linux subsystem in fact has its graphics being displayed on an Android host-system, I can use Android / Samsung gestures to take the screen-shots, which I provided above.
And so far, I see this new adventure as successful! Yay!
(Edit : )
One of the questions which does come up, is how files can be shared into and out of this Linux guest-system. One logical answer might seem to be, ‘By way of a Samba Mount, which can thereafter be navigated with the guest-system’s File Browser, as though it was a local folder.’ There’s a problem with that however.
This type of Linux guest-system is using the Android kernel, and on top of that, only has ‘fakeroot’. I.e., it will act as though the local directory-tree was a root directory, but not actually have root privileges with the kernel. And so while the standard way to do a Samba-mount from the command-line has become:
#mount -t cifs //192.168.0.10/service /mountpoint -o "user=username,password=password"
This is a request from a user-space application to a Linux kernel, to perform a CIFS-mount.
Android kernels won’t give us this privilege! And so instead we need to settle for an FTP-like shell that follows from
#smbclient //192.168.0.10/service -U username
Similarly, we could just naively be installing ‘Gigolo’ on our Linux guest-system, and not immediately know why that doesn’t work.
What works much better, is to take advantage of the fact that this Android app, puts all the guest-system’s folders into ‘/sdcard/GNURoot’ , under which there is also a folder named ‘/sdcard/GNURoot/home’ .
When I set up this LXDE desktop environment, I took care always to give ‘su dirk’ before launching ‘startlxde &’ . Further, on my Android host-system, I use a File Manager from ZenUI, which allows me to designate arbitrary Favorite Folders, that can be accessed from within the Android host-system with only a few taps. And, because both GNURoot and XSDL keep running in the background, even if I switch the UI to some other, Android app, this is easy to navigate in-session.
That would seem to be my best option for sharing the files.
(Edit 09/26/2017 : )
Even though some people might expect, that GUI applications should just install fine and then run, there is a problem with that premise.
XSDL is an emulated X-server that offers no hardware-acceleration, as it does not pass-through OpenGL to the Android host. In fact, by default, it does not even offer shared-memory support, unless we preload a special library for the execution of one application, that makes Android’s shared memory available to the application as though it was also Linux shared memory. The source of this library is stated on the page belonging to XSDL. And for media-players, this is the only way to go.
But, even some GUI-libraries now, such as Qt5 and in some cases Gtk3, actually require Direct-Rendering Infrastructure, in order to display their icons and application-windows correctly. And so many of those won’t run.
A logical question which this poses would be, ‘Why, then, does Blender run, which uses OpenGL for its editing view-ports?’
My answer would be, that if the OpenGL version being requested is only 1.x, then a software-rendering fallback is indeed possible (in this case, on the side of Linux packages).
This actually reminds me of how I once created a mini-game, and gave it to some of my friends, with instructions on how to install DirectX 7 on their Windows 98 computers. Even though DirectX 7 had to be installed, my game at the time also fell back to software-rendering, if no real GPU was detected.
But, when Microsoft came out with DirectX 8 and DirectX 9, software-rendering fallback was no longer possible.
Well, OpenGLES 1.x, which is often used just for compositing home-screens on smart-phones, or for displaying sketch-like visuals during a graphical editing process, roughly corresponds to DirectX 7 or 8, while OpenGL 2.x corresponds to DirectX 9. Any Linux applications that would require OpenGL / GLES 2.x , would not run.
(Edit 10/04/2017 : )
Because some tablet-owners might find that their available storage gets tight, with both Android and Linux installed, some way must exist to economize on the space which Linux is using, beyond just uninstalling some packages directly, i.e. to reclaim some storage used(, and without completely deleting the Linux sub-folder, which we invested so much of our time to set up, to a given level of functionality). Under Linux, we have the perfect commands for doing so:
apt-get autoremove apt-get clean
While it might be okay for the user just to give the first command, and, when it lists the packages which will be removed, just to acknowledge that list with ‘Y’ when prompted, I have been reluctant to do so, for the following reason:
This command will remove all packages – especially library-packages – which installed, placeholder packages do not depend on directly, under the assumption that all the GUI-based packages connect to the X-server that exists inside the Linux subsystem, and which ever runs.
There was some possibility for me to think, that there could be packages which are not stated as dependencies, but which installed applications may nevertheless need, in order to communicate properly with an externally-supplied X-server. I especially tend to be careful with this, having observed that Blender runs, even though the externally-installed X-server does not pass-through OpenGL messages.
What could be happening, is that the Linux-installed Mesa-OpenGL libraries are being invoked, that they essentially detect no hardware-capabilities, and that those libraries provide the fallback-implementation of OpenGL 1.x that Blender needs, using software. Yet, depending on what logic we use, those same libraries may no longer be counted as dependencies.
( By now I have learned, just by trying, that it’s completely safe to give these Linux-commands. I.e., after I have done so, even ‘Blender’ still runs.
A possible reason could be, that Before installing LXDE, I clicked on the little X-server icon in GNURoot, that launches a VNC-like session. Doing so installed some packages, which depend on other packages, that the use of VNC-like sessions requires.
I find that The VNC-like session provided by that icon does not meet my requirements as such, for which reason I use my GNURoot instance with the additional app XSDL, and I’d say, quite successfully so.
Further, even though it never runs, my package-installations on GNURoot did install a full X-server, which in turn depends on the Mesa libraries for OpenGL
The package which provides software-rendering of OpenGL, where OpenGL is meant to be hardware-rendered by default, is named
Finally, there is one respect in which I needed to customize my settings for ‘XSDL’. By default, dragging our fingers on the Android screen, only repositions the Linux mouse-pointer, while tapping anywhere on the screen, will click the Linux mouse-pointer, wherever that happens to be.
What we sometimes need to be able to do as well, is to hold down the left (Linux) mouse-button, and then drag the mouse with the button held down. In order to allow this with ‘XSDL’ and the touch-screen, there is an alternative to how the Left-Mouse-Button can be handled, which is to Hold Down Mouse Button, when the finger is held stationary on the Android screen, for more than a certain amount of time – in my case for 1 second. After that, dragging our finger also Left-Mouse-Button Drags the Linux mouse-emulation.
And now that I have this set, I also have fewer problems with Menus.