What is Shashlik?

What is Shashlik

The goal of Shashlik is to provide a way to run Android applications on a standard Linux desktop as easily and simply as possible.

Under the hood

The easiest way to run an Android app correctly is to simply run Android. It’s a linux base that we can nest inside our session. OpenGL and graphics are all rendered on the host ensuring fast performance.

Shashlik provides an incredibly stripped down Android base which boots directly into the loaded app, but with a running activity manager and daemons so that intents still work correctly.

Building

Prerequisites

First download and install “repo”. A tool that makes it easier to work with multiple git repositories at once.

$ mkdir ~/bin
$ PATH=~/bin:$PATH

Download the repo tool and make it executable

$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo

##Getting the code

Create a new directory, and start a repo sync with our manifest

mkdir shashlik
cd shashlik
repo init -u https://github.com/shashlik/shashlik-manifest
repo sync

Note: The code base is huge. As in, really huge.

Learn more about repo at https://source.android.com/source/using-repo.html

Compiling

Source a script containing env vars and setup, and hit make

source build/envsetup.sh
make

Installation

Installation is currently a manual process as the state changes rapidly.
It’s fairly obvious from the debian files which files are needed where.

Shashlik Components

Manifest

This contains an XML file of all repos to fetch to build an android image.
It contains a seriously stripped down Lollipop base plus Shashlik modifications and additional modules.

Shashlikd

This runs in Android space and is responsible for a few things

* Drawing a custom bootsplash. We override the stock one with a version that shows the icon of the app to be launched

* Drawing the back buttons (normally done by Android’s SystemUI, but we don’t want all the overhead of that)

* Notification recieving and passing to the host (WIP)

Shashlik-runtime

This is the desktop side of integration layer. It provides small scripts to install APKs, extracting the icon and such into a desktop menu and copying the relevant files.

It also provides the startup script which launched the emulator installing the APK,

Qemu fork

As the name suggests this contains a fork of the android emulator from the SDK.
It is modified to show the window icon and title of the app we’re running, not look like an emulator.

The other repos

These come from a former approach which tried to target running Android at a lower level. They should be ignored.

Overall plans

Near Future

* Drop manual aapt parsing. Approach depends a bit on whether I stick with the prototype python, or switch it to a small Qt app.

* Drop adb. Shashlikd can communicate out to our host over HTTP. Client fetching from host is better than host pushing to client as we avoid startup races.

* Fix network.

* Release as user builds rather than userdebug. Self explanatory. Saves some Mbs.

* Predex?

* Continue cutting down on the manifest to be constantly smaller.

* Simple window resizing. Keep aspect ratio, just adjust the window scale.

* More integration with notification and things. We can

* Handle device rotation. Apps signal whether they are drawing horizontally to the WM. It’s “just” a case of forwarding that.

* Files… qemu has virtfs, android also has Fuse. Lots of options. We can also go with; Fake SD card, a fileProvider intent, or something else…dunno.

* Tidy up packaging. Maybe split manifests for Client and Host sides? Then packagers can build one easily, and I can fetch host isos easily.

Longer Future

We only need the VM because we need a kernel with binder.

If we can rewrite libbinder in userspace (it’s just a socket…how hard can it be?) then we can move the Shashlik world into simly being a container.

Graphics and devices can still work the same way proxying openGL through a socket between client and env base.

Contributing

Removing a module

The main thing we’re doing in Shashlik at the moment is stripping Android down.

There are 3 ways to remove a module:

  • Remove it from the manifest. If possible do this, as it saves downloading and parsing the makefile
  • add LOCAL_MODULE_OVERRIDES into a different module. shashlikd does this to replace systemui for example
  • Remove it from the PRODUCT_PACKAGES list in the shashlik product in build.

Ideally we want our delta with Android to be as small as possible with regards to packages and frameworks.

Some modules are subjective; For example the Camera app seems like a useless thing to include.
However some apps (Dulux paint app for example) will use a camera intent to get a photo; that requires the app running.

Merging changes

Open a pull request, standard github procedure.

  • RaviChandarana

    Is there any chance we could see some screenshots? This seems like an excellent project!

    • leinir

      Screenshots will be forthcoming! For now, have a gander at the presentation video from Akademy over on the News page :) Thank you very much for the kind words!

  • http://ryeingoddard.com Goddard

    Awesome project…keep up the good work.

  • Neon Samurai

    Really looking forward to this. Will there be a port for the ubuntu phone, to run apps from the google play store on it?

  • cheekyngeeky

    This could be a game changer.

  • pepeliso

    great work!

  • https://www.youtube.com/user/TeleGamerymas/videos luis alejandro cv

    interesante pero se ve algo complicado esperare que se una algun repo mas popular

    • Jose Barakat

      Me suena bastante a la forma de funcionar de Wine. Interesante. Deberían hacer un PPA en Launchpad para facilitar la instalación de los paquetes.

  • arnaudober

    Will be the performances the same between Android device and app on Ubuntu Touch? (I hope at least, usable…)

  • Alex Elsayed

    Any chance of these instructions getting corrected to actually work? Up to the envsetup.sh step it seems to go just fine, but there’s just a cascade of errors if you try to actually build:

    – There’s no bootstrap.sh, so soong complains
    – If you copy the one from soong (to the toplevel), it yells about build/soong not being there
    – If you clone that into place, it demands build/blueprint
    – If you satisfy that, it yells about not having go prebuilts
    – If you grab those, it fails due to needing ninja prebuilts
    – If you do that, it complains about missing Android.bp
    – If you copy that from build/soong to the toplevel, it starts building…

    …and then explodes:

    “`
    FAILED: out/soong/.bootstrap/bin/minibp -t -m ./build/soong/build.ninja.in -b out/soong -d out/soong/.bootstrap/bootstrap.ninja.in.d -o out/soong/.bootstrap/bootstrap.ninja.in Android.bp
    error: Android.bp:170:1: “soong-java” depends on undefined module “blueprint”
    error: Android.bp:170:1: “soong-java” depends on undefined module “blueprint-pathtools”
    [41/43] minibp out/soong/.bootstrap/primary.ninja.in
    FAILED: out/soong/.bootstrap/bin/minibp –build-primary -t -m ./build/soong/build.ninja.in –timestamp out/soong/.bootstrap/primary.ninja.in.timestamp –timestampdep out/soong/.bootstrap/primary.ninja.in.timestamp.d -b out/soong -d out/soong/.bootstrap/primary.ninja.in.d -o out/soong/.bootstrap/primary.ninja.in Android.bp
    error: Android.bp:13:1: “soong_build” depends on undefined module “blueprint”
    error: Android.bp:13:1: “soong_build” depends on undefined module “blueprint-bootstrap”
    ninja: error: rebuilding ‘out/soong/build.ninja': subcommand failed
    build/core/soong.mk:80: recipe for target ‘run_soong’ failed
    make: *** [run_soong] Error 1
    “`

    At this point, I gave up.

    • Michael DeGuzis

      Same issue here. Luckily the .deb package resolves the dependencies fine here. There are only a few to worry about, some 32 bit packages. If interested, just run ‘ar -x package.deb’ on the Debian package. Untar the control.tar.gz file to check it out. Maybe at some point I’ll try this again an a Digitial Ocean droplet, but the download size is massive (obviously). It’s a shame that he doesn’t provide the debian file / archive anywhere. I don’t expect the dev to upload that massive orig.tar.gz, but at least the debian tarball would be nice to see how it’s built.

      • Alex Elsayed

        The problem isn’t with (system) dependencies – it’s that the Android buildsystem has changed significantly since whatever version these docs were written against, they’ve updated the repositories at least partially to deal with it, and they’ve completely failed to update the docs.

        So regardless of whether the .deb package resolves the dependencies, the actual _code_ does not build.

        In addition, I don’t think the debs were necessarily even built against the source that’s on github – I’m not finding any tags that even roughly correspond to the debs.

  • Michael DeGuzis

    Which one of the repositories contains the 9.3 version tag (the latest I saw in the static deb repo)? If I start building this natively on Debian/SteamOS for my SteamOS-Tools project, I want to be able to watch the repo, or source the latest version tag / release. Is this possible?

  • flutterbrony

    Awesome !
    Hope you still working on it ^^
    Did the sensors working with it ? (I only test on my desktop computer, but I’ll try on my Asus T100 ^^ If I can use it well, I’ll remove the dual boot with Android and Manjaro on it and only use Manjaro with sashlik on it ! ^^)

  • name1234

    You really force users of your website to use smooth scroll? What the hell is wrong with you?

  • geek42

    the android repo is too huge

  • Bodor Csaba

    so the repo is 26.6 Gigabytes. And the compilation fails instantly with the message “make: *** No rule to make target ‘prebuilts/build-tools/linux-x86/bin/ckati’, needed by ‘out/build-aosp_arm.ninja’. Stop.”

    In this stage, you should start this page with something like “this is our repo, but it does not compile, don’t waste your time and bandwidth”.

    It would be nice to see a fedora rpm release.