Shashlik: A New Way To Run Android Apps On Linux

[TitanFighter]

Despite the debates above, the funniest thing is the russian name - shashlik)
Sounds like Wine

[lunarcloud]

Naturally it is fully based on KDE Libraries, because fuck it, who needs a solution that works for everybody when you can use KDE instead.

If every KDE user can install GTK libraries to use chrome / firefox / gimp, then you can install a couple KDE libraries in other DEs. KDE's new frameworks are really modular anyway, so you'll only end up with stuff that's absolutely needed instead of everything.

Your other criticisms are harsh, but not unfounded.

[M1kkko]

Is this something similar to Wine? I always thought it should be relatively easy to run Android apps on Linux without a VM (at least for the Java apps).

Android applications are packaged Java applications, so they require a Java virtual machine to run. For this purpose Android has its own virtual machine/runtime environment called Dalvik (and a newer one called ART - android runtime), but I don't think there has yet been an open source port for general-purpose desktops. This situation differs from Wine in that the Android codebase including Dalvik are open source and licensed under a liberal license, whereas Windows is closed-source and requires reverse-engineering.

[Delgarde]

Android applications are packaged Java applications, so they require a Java virtual machine to run.

Not quite. Android apps are written in the Java language, but the environment they run in is *not* a JVM at all. Dalvik/ART is equivalent to one, but is in no way compatible with the actual JVM, as the apps are compiled with Google's own compiler into a bytecode format unique to Google's stack. The only thing they have in common is that the source code is in the same language.

[mmstick]

Or... show me a media player that can even remotely stand up to MX Player (Pro). I'm pretty sure you won't find anything; I had a look at all the totally over-hyped media players (Audio AND Video) and none of them cuts it for the job (I've not even found anything on Windows that can stand up to TuneIn Radio or Pocket Casts). Totem (now called "Video" in Gnome3) is total garbage (what they call a "Settings menu" is what I call "fail for life"), SMplayer/UMplayer are nice but have severe problems when it comes to vdpau hardware acceleration, audio/podcast managers like Clementine/Rythmbox/Banshee/(continue with overhyped garbage at will) are nothing more than a joke as well (why did WinAMP on Windows had to die?). Okay, on Windows there's at least Media Player Classic Home Cinema that plays on the same level as MX Player does on Android.

Where have you been the last two years? Bomi and MPV knock all of those out of the park. It even gives functioning motion interpolation. Mplayer has been outdated technology since MPV took over. Why people still contribute to it, I have no idea. VDPAU works perfectly fine on all of my AMD systems using open source drivers.

[brotiger]

If every KDE user can install GTK libraries to use chrome / firefox / gimp, then you can install a couple KDE libraries in other DEs. KDE's new frameworks are really modular anyway, so you'll only end up with stuff that's absolutely needed instead of everything.

KDE doesn't build libraries. It builds components for a framework.

GTK and all the glib stuff is written in plain C. Because just about every language on the planet can link against or wrap around a native library generated with a C compiler, you can use GTK and glib all the time. glib doesn't dictate how your application has to be structured, and it doesn't force you to use all of it. It doesn't need any additional tools. GTK and glib provide immense value for everybody else, heck, they can even be used in combination with Qt.

KDE Frameworks on the other hand can only be used with Qt's version of C++, you need a Meta-Compiler to use them, you can't link them against anything else than C++, you can only use them from other languages with great pain, and they provide no value for anybody else than people using Qt. Let's for example look at the KArchive component from the KDE Frameworks. If this component had been written with the intention of benefiting everybody in the FOSS ecosystem, they would have built a C library that can handle multiple archive formats and just outputs a stream of bytes, built a C++ wrapper around it that offers an iostream, and then built a Qt wrapper around it that offers a QIODevice. Everybody wins. Instead of that they just built a pure Qt component. Great. 90% of the software on the market cannot and will not suddenly switch to Qt just so they can use this component.

Software Architects build independent, reusable libraries, so you can just take a bunch of them, wire them together and build something bigger. Hackers build Frameworks instead, Frameworks that are not reusable and confine you to the model of thinking of a Hacker.

[emblemparade]

Sigh. I'm really tired of this "Android is not Linux" nonsense. Android is Linux. Linux is a general purpose operating system which targets many hardware platforms: desktops, mobile phones, embedded controllers, servers. and virtualized servers. Even the talk's blurb falls into this nonsense:

Android is, it is generally accepted, a Linux system. Except it is not what most of us recognise as Linux. Yes, it does use the kernel, but the levels above that are very different to what we would recognise.

I don't know who "most of us" is here. Are you talking users of desktop Linux? Those are without doubt the smallest community of users of Linux. If your desktop Fedora or Arch or Ubuntu is the only Linux you "recognise" than you must live in a very tiny bubble. Most commits to Linux have nothing to do with running it on a desktop.

Other imprecisions:

* Most Android apps indeed run on the Dalvik/ART later (which is utterly not the JVM), but also rely on a large amount of Android APIs that are in turn tied to the hardware platforms (phones and tablets). Adding to the complication is that more and more apps rely on APIs provided by proprietary Google libraries that must be downloaded from the Google Play store. Such apps will not even run on a pure open source Android environment, let alone on a desktop Linux. The bottom line is that it's not enough to just run Dalvik/ART on your desktop. The challenge is to provide equivalents of all these various APIs: hard enough to do when they're open source, and very hard to do when they are proprietary. If Shashlik will indeed manage to do this, it will be a huge achievement, equivalent in scope to WINE. Not at all impossible, but very tedious work.

* Not all Android apps are Dalvik/ART! Many, especially games, are written in native code (using the Android NDK), which end up running in a sandboxed environment. How do they support the various CPU platforms? By actually including all binaries in the download. Since x86 phones and tablets have been around for a while, this does mean that these apps are very good candidates for running on a desktop Linux, because they are already native and rely on very few Android APIs.

[ElectricPrism]

According to my understanding you can already do this with Archon.

Sure I ran Photoshop Express via apk but it wasn't a miracle or anything Most Android Apps aren't that useful imo.

[Dorsai!]

I don't know who "most of us" is here. Are you talking users of desktop Linux? Those are without doubt the smallest community of users of Linux. If your desktop Fedora or Arch or Ubuntu is the only Linux you "recognise" than you must live in a very tiny bubble. Most commits to Linux have nothing to do with running it on a desktop.

I am pretty sure that he meant the classical GNU/Linux user space, in the way you will find it on practically every desktop, notebook, but also servers and most embedded devices. All in all this will make up the majority (android aside) in terms of user numbers and can very well be classified as "we". Practically the only systems I can imagine that are diverging from the common Linux userspace paradigm are a few big clusters/supercomputers, some heavily containered systems (although it might be argued how different they really are once you break the containers down) and android.

[geearf]

Where have you been the last two years? Bomi and MPV knock all of those out of the park. It even gives functioning motion interpolation. Mplayer has been outdated technology since MPV took over. Why people still contribute to it, I have no idea. VDPAU works perfectly fine on all of my AMD systems using open source drivers.

Thanks for this, I didn't know mpv had it!
Last time I played with vapoursynth but it was way too slow (although it's not exactly the same thing in the end).