Alien Dalvik on older devices has the same naming as Android App support on newer devices

Hey folks,

it seems that Alien Dalvik on older devices and Android App Support on newer devices have the same naming, which is quite confusing, as it suggests the users of older devices to get a lot updates, even if that for their devices isn’t the case. I was quite eager to see a signed system image, additional sharing options,… but this is all not the case with Alien Dalvik. Maybe its just by mistake, or a clever strategy of Jolla. But if the naming is equal, also the base should be equal. I don’t get why Jolla isn’t bringing all possible devices to the same base, as it apparently would save a lot of trouble. And these users ciuld by a new Android support license, which would benefit Jolla. Otherwise, we have the Android scenario, updatable devices, but no updates coming, and a lot of different bases, which means a lot of work for the Jolla Team and disappoinred SFOS users. What will be the strategy of Jolla for those questions/problems!?

Or let the community do the work…

1 Like

There were attemps to do so, but apparently its not that trivial:

I only think that if all the bases were that similar, that porting it to another device would just be the changing of drivers, this would bring SFOS really forward as some devices would not get stuck on a certain version, and a lot of devices could be added to the program :slight_smile:

“Android App Support” is AlienDalvik! It is just an non-technical / marketing name for it.
Jolla introduced that marketing name some time after they had taken over the development of AlienDalvik from Myriad Group.

It is build upon AOSP code (Android Open Source Project), which is also what LineageOS and other Android distributions (“ROMs”) use.

And it comes in different versions, which (mostly but not only) depend on a minimal Android vendor kernel (i.e., an adapted Linux) version used.

It is the specific Android vendor kernel used by Jolla, which prevents the use of AlienDalvik 8.1, 9 and 10 on all devices older than the Xperia XA2.
Just as the the specific Android vendor kernel Jolla adapted for SailfishOS on the Jolla 1 phone (from Qualcomm) prevented Jolla from deploying AlienDalvik 4.4 on it, while the Jolla C / Intex Aquafish, Jolla Tablet and Xperia X use that AlienDalvik version.

Thus, if you want a newer AlienDalvik on any of these old devices, you first have to obtain an sufficiently new Android vendor kernel for them, which supports at least Android 8.1 (because no AOSP 5, 6, or 7 based AlienDalvik exists).
Then you have to adapt that kernel and some low-level parts of SailfishOS to run well together.

Side note: IIRC Qualcomm provided a sufficiently new Android vendor kernel for the Jolla 1 hardware to run Android 4.4 and Sony a sufficiently new Android vendor kernel for the Xperia X to run Android 8.1, though Jolla has not taken the effort to adapt these kernel sources for the use in SailfishOS: Adapting and testing takes quite some manpower and Jolla rather put their slim resources into adapting the vendor kernels of newer devices, which is absolutely the right decision from a business perspective.

But it is all Free Software, so you can start doing this right away, if you want.

TL;DR: No, Jolla is not cheating, IMO you should not confuse marketing and technical names (take a look at the RPM name: It always was & is “aliendalvik”).
And they are not artificially holding back newer AlienDalvik (“Android App Support”) versions for older devices, they just have no incentive to perform the necessary work to make this happen.

P.S.: And as these old devices are old (specifically their battery are worn, but they also use outdated hardware etc.) my advice is: Do buy a newer device!

P.P.S.: Although I do own a Jolla 1 and an Xperia X and I would love to install and use a newer kernel and a newer AlienDalvik on them, I do not want Jolla to put significant resources into that! I rather would like to see Jolla performing more thorough quality assurance, so SailfishOS becomes less buggy. From my perspective they have created more and more serious bugs with each SailfishOS release since 3.2.1 than they fixed, rendering all these releases unsuitable for my real life usage (though I have some hope the 4.3.0 may be good enough).


Thanks @olf for this long and funded answer :slight_smile: . Sorry if i am asking back. But i understood, that the Android Support of the older devices like Xperia X was based on Dalvik technology, the newer Android App Support on Lxc containers, what also explains, the continuous new functions. Is Alien Dalvik also just an Lxc container? But maybe if we are lucky, the Waydroid team, will provide us, with a newer Android support, for our old Xperia devices. If i buy a new device, i will probably opt for the Pinephone Pro, as for the Sony devices their will alwaysort be the same problem, kernel updates and support periods, as for the Pinephone, i understood that the base is pure Linux, so that there will be not problems with Kernel support or also Android versions, and you could just put an Android VM on top of it. So that probably will be the better choice with a much longer support. It is clear to me that hardware is a limitation for such stuff and that one day, for all devices there will be a support end. So maybe i install UBtouch on my old Xperia X and go for the Pinephone Pro as soon as it comes out :slight_smile:

Sorry, you are thoroughly mixing up technical concepts, resulting in a convoluted pile of technical buzzwords which just does not make sense.

  1. Googles “Dalvik VM” is the Java Virtual Machine (JVM) all Android applications have to use on Android < 5.
    Starting with Android 5 Google also allowed “native apps”, which are regular binaries (“executables”). But the “Dalvik VM” is also still present, otherwise old Android apps would not be able to run.
  2. Because a JVM provides some isolation, Myriad Group originally designed AlienDalvik without any additional isolation mechanisms.
    When Jolla created AlienDalvik 8.1 they chose to run the whole AOSP stack (and thus also all installed Android apps) inside an LXC container in order to isolate that from the SailfishOS proper.
    Anbox / Waydroid uses exactly the same architecture: AOSP with its apps runs in an LXC container on a Linux distribution.

Please stop pondering about this, it will not get you anywhere.


Those links don’t really prove that statement (beyond a package name level). Already at the second link it says “We have added Android 8.1 apps support”. They could just as well have chosen the same package name (despite it being an entirely different thing under the hood) for some more abstract reason, like it looking the same in store.

I suspect it is an almost full reboot of the efforts; based more on sfdroid rather than Alien Dalvik.

But apart from that; i completely agree with you, and your conclusions/advice still stands.

I’m certainly not an Android expert, but it’s quite clear that Dalvik was a traditional JVM with interpreter and later a JIT compiler. The newer Android Runtime ART does compile the Java bytecode to native machine code ahead of time, but the most apps are still shipped as Java bytecode. ART does not ship with an included Dalvik JVM.

Anyway, using Dalvik or Alien Dalvik as base for the recent Sailfish Android App Support would be rather pointless. No small company has the resources to backport all features to such an outdated architecture to support Android >=5 on Dalvik. There is no indication that “Jolla has taken over Alien Dalvik”.

Yes, that is exactly the point: What Jolla’s release notes for SailfishOS 3.0.1 called “Alien Dalvik 8.1” started to be called "Android 8.1 apps support” in release notes for SailfishOS 3.0.2 and later.
It is exactly the same thing these two release notes address.

I suspect it is an almost full reboot of the efforts;

Sure it was: Up to AlienDalvik 4.4 Jolla payed Myriad Group for the work.
But Myriad Group ceased to develop it any further, so Jolla bought the rights to do that on their own.
The crucial part about AlienDalvik is not the AOSP it contains, but the integration framework to interact with the “host OS”: Clipboard, Network, Notifications etc. (and the missing stuff: WiFi as such, Bluetooth, NFC etc.)

based more on sfdroid rather than Alien Dalvik.

Definitely not!
SFdroid / Anbox / Waydroid is GPL-v3 licensed.

If you look at the files you have on your SailfishOS device (e.g., the corresponding systemd units and AlienDalvik configuration files) you will find all that nicely retraceable (e.g. in the copyright notices, their dates and other comments there).

1 Like

Sorry, you are missing the point:

  • Dalvik VM and ART are just the names for the (technically quite) different stages of development of Google’s Java Runtime, but are irrelevant for the topic discussed here: To obtain a more recent Android runtime environment for old devices with SailfishOS rsp. the reasons why this is infeasible.
  • AlienDalvik is the product name for a framework to let an AOSP run on a host OS, originally developed and distributed by the Myriad Group. Back then it could integrate Myriad Group’s Dalvik Turbo VM, which is / was the counterpart to Googles Dalvik VM.
    Jolla was not their only customer and Myriad Group demonstrated AlienDalvik to also run on WinCE and Linux for MIPS processors (besides Linux on ARM and x86).
  • Technically AlienDalvik is primarily an integration framework to interact with the “host OS”: Clipboard, Network, Notifications etc. (and the missing stuff: WiFi as such, Bluetooth, NFC etc.)

Anyway, using Dalvik or Alien Dalvik as base […]

They are two completely different things!
The “Dalvik” in AlienDalvik’s name might be misleading, but it was coined at a time when all Android apps ran on the Dalvik VM (on a real Android), and then the name stayed.

Thus no reason to jump to technical conclusions, which are only based on a product name!
Rather take a look at what AlienDalvik is in practice on your SailfishOS device.

There is no indication that “Jolla has taken over Alien Dalvik”.

If you look at the files you have on your SailfishOS device (e.g., the corresponding systemd units and AlienDalvik configuration files) you will find all that nicely retraceable (e.g. in the copyright notices, their dates and other comments there).

But the whole point was not any technical details of Google’s Java runtime environments.
The point was and is that the integration of an AOSP ≥ 5 into AlienDalvik made some proper isolation from the host OS necessary (due to Google allowing for “native apps”), for which Jolla chose LXC.
And even that was a minor technical aspect, only to explain the proper terms and basic design of AlienDalvik.

P.S.: And all this technical nitpicking will not help @Firefox84 to get a single inch closer to having a newer AlienDalivik on his Xperia X!

1 Like

@olf thanks for all the facts you provided to this discussion. Jolla made quite clear they do not intend to update wether the Android support nor the Kernel base for Xperia X. With Android support you could say. Who cares as the goal is to get away from Android. But by not updating the base and creating several releases one beside the other and quite similar. Jolla is going in the same direction then Google. And tgey will have to update the different release for quite some time. So the question is, what is less work, updating several different releases each time, backporting stuff, etc. Or bringing all to the same base if possible, and then working from there. I just find it interesting to get quite long release notes and later realising that most of the updates are not coming to your device. My strategy will be waiting for a possible waydroid solution if this is not coming. Then going for a Pinephone Pro, for which Jolla will then hopefully offer Android App Support some time in the future. Which would bring an easy to update device with the possibility to use Android. :slight_smile:

@olf: thanks. Seems indeed that the name should never have been AlienDalvik at all.

You… understand why the name was picked, right? Google’s VM is literally called Dalvik, Alien Dalvik makes direct reference to it being a VM not created or maintained by Google, therefore, an Alien Dalvik.

@Firefox84 Optimizing the performance of ostensibly two operating systems at once, the core Linux base and the container layer, keeping integration between the two, and leaving enough memory is a challenge as well. And with how old these phones are, while it would improve compatibility for the device, it would probably just as well cause usability issues as the device struggles to maintain the memory for it all. As it is, current versions of Sailfish OS for XA2 and beyond (running Alien Dalvik builds based on Android 8, 9, or 10, moderately loaded with F-Droid, microG, and possibly more than a few Android apps for some users who need their phone for more than basic communication) experience crash scenarios, either with “Android App Support” failing and requiring a few restarts, or a sort of “warming up” period where no activity on the Android side happens, OR Lipstick fully crashing, requiring all the apps to close, the UI to reload, and once again, Android App Support needing to start again.

That’s not considering the other myriad of issues, like inconsistent network bridging from SFOS side to Android (where Fernschreiber on SFOS will connect, but Telegram on AD doesn’t, which is weird, because they both connect to the same servers) or poor GPS lock, either in AD or on SFOS too. And Tracker-miner-FS stopping on… UI reload, causing photos and videos to no longer bridge over to Android (which has caught me many times when I take a picture, go to an Android app, and cannot pull that picture up, I must restart the entire phone to fix this issue). Those are just a couple issues, and that’s covering devices that have good specs over all. If these functions and features are struggling on current hardware, how do you expect all that to be ported to a device that runs slower and has less memory? It’s just not possible. Jolla are better putting their resources exclusively into the main OS for those old devices and not compromising the parts that do work.

1 Like