How the Obsolescence of Dalvik Does Not Even Represent an Inconsistency

There was a development with Android, which slipped my attention, and which took place during or after the advent of Android 4.4 (KitKat).

In general, it has always been a fact that Android application-programmers were encouraged to write a kind of source-code, which was identical in its syntax to Java, and which was compiled by their IDE into a kind of bytecode. Only, for many years this language was not officially named Java, instead officially being named Dalvik for some time. Exactly as it goes with Java, this bytecode was then interpreted by a central component of the Android O/S (although, there exist computers on which the JVM is not central to the O/S).

This means, devs were discouraged but not forbidden, from writing their apps in C++ , which would have been compiled directly into native code. In fact, the Native Development Kit has always been an (optional) part of “Android Studio”.

But since Android 5+ (Lollipop), the use of this interpreter has been replaced with something called the Android Runtime (ART). This fact does not present me with much of an inconsistency, only a late awareness of progress.

Even when I was learning some of the basics of programming in Java, one piece of technology which had a name, was a so-called “Flash Compiler”. This was in fact distinct from a “JIT Compiler”, in that the JIT compiler would use the source-code, in order to compile parts of it into native code, while a flash-compiler would only need to use bytecode, in order to derive native code.

So, if the newer Android Runtime flash-compiles the bytecode, this does not change the fact, that devs are writing source-code, which is by default still Java, and initially being compiled by their IDE, into bytecode.

Clearly though, there is a speed-improvement in flash-compiling the bytecode and then executing the resulting native code, over interpreting the bytecode.


 

Yet, the speed-improvement which was once thought to exist in RISC-Chip CPUs, has largely vanished over the History of Computing. One original premise behind RISC-Machines was, that they could be made to run at a higher clock-speed, than Complex Instruction Set (CISC) Computers, and that due to this increase in clock-speed, the RISC-Machines could eventually be made faster.

In addition, early CISC-Machines failed to use concurrency well, in order to execute a number of operations simultaneously. By doing this, modern CISC-Machines also obtain low numbers of clock-cycles per instruction. But I think that this subject will remain in debate, as long as practical CISC-Machines have not exploited concurrency as much as theory should permit.

Since an optimizing compiler generally has the option of compiling source-code into simpler instructions, even when targeting a CISC-Machine, it would follow that realistic source-code needs to be compiled into longer sequences of RISC-Machine instructions.

This debate began before the days, when a CPU had become one chip. Since the CPU is by now a single chip, communication at the speed of light permits a CISC-Machine to have as high a clock-speed as a RISC-Machine. OTOH, the power consumption of a RISC Chip may still be slightly better.

And, as long as the CPU of Android devices only needed to execute a Bytecode Interpreter, this set of instructions could be optimized again, for the purpose of doing so, on a RISC-Machine. But, if we compare the speeds of modern RISC and CISC -Machines running optimized, native code – i.e., compiled C++ – I think it’s clear that the CISC-Machines, including the ones that were meant to run Windows or Linux on, outperform RISC machines.

(Edit 10/09/2017 : )

I believe that there exist specific situations in which a RISC-Machine runs faster, and that a lot of that depends on what language of source-code is being compiled. In the case of RISC-Machines, the compiler has fewer options to optimize the code, than it would with CISC-Machines.

Continue reading How the Obsolescence of Dalvik Does Not Even Represent an Inconsistency

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 : )

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

I now have Linux installed on my Samsung Galaxy Tab S.

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 !

screenshot_2017-09-24-06-00-25

screenshot_2017-09-24-05-59-53

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 : )

Continue reading I now have Linux installed on my Samsung Galaxy Tab S.

New Potential in my Galaxy Tab S.

As I wrote in this earlier posting, I believe that my ancient Galaxy Tab S First Generation (Android) tablet has finally bit the dust, due to File System Corruption.

This is not just due to the wonky behavior following the latest hard-boot (during a routine software-update no less), but also because over the years, the amount of free memory on it has become very small, even though I have uninstalled most of the apps that were once installed on it. Typically, failure to reclaim unused space, is one of the earliest signs of FS corruption.

Depending on how one looks at it, visualizing this as a terminally-crashed tablet can have its upside, especially since my needs for a stock Android tablet are met in my ownership of a Pixel C. What this actually means is that I can regard the present installation on the Tab S as expendable, which means that eventually, I’d be able to experiment with it as I wish. For example, I might eventually want to root the Tab S, or install Linux on it…

But one fact which I seem to gather after some reading, is that even to install Linux on Android-capable H/W, does not take place as it does with PCs, where the Linux system is the only running O/S. Instead, Android-capable H/W seems to require that one way or another, we install Linux alongside Android. Thus, unless I get Android working again on the tablet first, I also wouldn’t be able to get Linux working on it.

Further, rooting an Android device does not (necessarily) cause the firmware to be flashed. Instead, if we want to flash the firmware, this is a separate operation which can also be done.

Long story short, whether I’ll ever be able to resurrect that tablet, depends on how it’s partitioned, and in which partitions I suspect the FS corruption has hit.

For example, if I just root, then the data and apps on the ‘/sdcard’ will not even be affected, and if that’s where the FS corruption was, the FS corruption will just stay there. The similar effect would take place, if I was to flash a custom ROM Image on the device, which would affect the ‘/system’ partition and/or the ‘/boot’ partition, but not affect the ‘/sdcard’ .

I would strongly suspect that the FS corruption is on the ‘/sdcard’ , especially since I wasn’t updating the O/S, when the latest crash took place. And what that would seem to suggest, is that my next step should actually be, just to perform a factory reset: The simplest advice sometimes given! That should reset the ‘/sdcard’ , and the ‘/data’ partition, mainly.

If that causes the tablet to become stable again, Then I could proceed next, to root, to install Linux, etc., etc., etc.. Or, I could just recommence with Android, with more reclaimed memory, and with a stable tablet…

Dirk