We're hiring!
*

Running Android next to Wayland

Robert Foss avatar

Robert Foss
April 01, 2019

Share this post:

It's now possible to run Android applications in the same graphical environment as regular Wayland Linux applications with full 3D acceleration.

Running Android has some advantages compared to native Linux applications, for example with regard to the availability of applications and application developers.

For current non-Android systems, this work enables a path forward to running Android applications in the same graphical environment as traditional non-Android applications are run.

What is SPURV?

SPURV is our experimental containerized Android environment, and this is a quick overview of what it is.

It's aptly named after the first robotic fish since a common Android naming scheme is fish-themed names. Much like its spiritual ancestor Goldfish, the Android emulator.

Other Android Compatibility Layers

This means that Anbox which is LXC based, is different from SPURV in terms of how hardware is accessed. The hardware access that Anbox provides in indirect, and through the Qemu Pipes functionality, which is something it adopted from the Android (goldfish) emulator.

Shashlik and Genimobile are Android on Linux integration layers both based on Qemu, which means even better security properties than Anbox and certainly SPURV, but at the cost of an even larger performance penalty.

Direct Hardware Access

SPURV is different from other Linux desktop integrations for Android since it offers direct hardware access to the Android application. This is a choice we made for performance reasons. But has drawbacks, especially when it comes to security.

Using direct hardware access does however grant us increased GPU and CPU performance, which is important since we're targeting embedded platforms which can have very limited resources.

Components

SPURV consists of a few different parts, all living in the same project.

An overview of the SPURV stack.
An overview of the SPURV stack.

 

Android target device

This component integrates SPURV into Android, and it does so by using the device infrastructure that the Android codebase provides.

Devices are normally used to customize an Android build to the specific needs of a given hardware platform, like a new smartphone SOC. In the case of SPURV, we're targeting being run inside of a systemd-nspawn container.

SPURV Audio

This component bridges the Android Audio Hardware Abtraction Layer (HAL) to the host PulseAudio stack.

SPURV HWComposer

Integrates Android windows into Wayland. It does so by implementing a HWC-to-Wayland bridge.

HWC is the Android API for implementing display & buffer management, and what it essentially does in interpret all of the different display buffers that Android applications produce, and organizes them into one cohesive Desktop.

This protocol is conceptually not unlike the Wayland protocol, which allows for the HWC to be translated into Wayland. This is essentially what the SPURV HWComposer does.

Additionally it deals with input, like touch screen events and passes them along from Wayland to Android, this however is unrelated to the HWC API.

How does it work?

The SPURV Android target device behaves as a faux Android device, and tailors the Android build to our requirements.

Functions SPURV performs:

  • Customizes defaults.
  • Configures network.
  • Enables an audio bridge from Android to PulseAudio.
  • Enables a graphics bridge from Android to Wayland.

How can I use it?

Full build instructions as can be found on our GitLab for the SPURV project.

An overview of setting up:

  • Fetch Android (AOSP) and the Linux kernel,
  • Integrate SPURV into Android,
  • Build Android & Linux Kernel,
  • Build a debootstrap based root filesystem, and
  • Flash Kernel, Android and root filesystem to the device of your choice.

What comes next?

The next few steps will be adding support for more hardware platforms in our build scripts, but also optimizing the experience.

In no particular order, this is what we would like to look at next:

  • Bring-up on the i.MX8M with the etnaviv graphics driver.
  • Slimming things down so it takes less time to start an app and consumes less RAM for the case where the goal is to just to run a single app.
  • Bring-up on x86 with Ubuntu, publishing runtime binaries.

Caveats

The way SPURV is implemented means that a full OS is being run in a container, which has implications both positive and negative.

One of the positive effects is increased isolation of Android applications, which means improved security and privacy for potentially untrusted applications.

Additionally, this approach allows for Android applications to be run next to Wayland based applications in a desktop environment.

The downsides relate to hardware access and performance. All hardware access that is needed by Android has to be passed into the container. Besides manually having to configure such access using systemd-nspawn, there are also performance costs associated with running a container. One part of this is the static cost of having to load an entire OS on top of the base OS, but there are also additional runtime performance penalties for applications in the container.

Acknowledgements

      • Pengutronix
      • Zodiac
      • Boundary Devices

 


Visit Robert's blog.

Comments (64)

  1. Linas:
    Apr 02, 2019 at 08:12 AM

    This seems very interesting. Would it be possible to run SPURV on a regular desktop Linux like Ubuntu? What is the ultimate goal of the project?

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 02, 2019 at 02:36 PM

      Hey Linas,

      This could indeed be run on a desktop, as long as you desktop is Wayland powered.
      The AOSP build would however have to be built against the CPU architecture of your desktop.


      Rob.

      Reply to this comment

      Reply to this comment

      1. mikhailnov:
        Apr 02, 2019 at 03:55 PM

        Can't wayland be ran in a separate window of top of Xorg session?

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Apr 02, 2019 at 04:02 PM

          Well, you can do it the other way around, and run X applications on top of Wayland using XWayland.

          In the video I'm running kolourpaint using XWayland in this way actually.

          Reply to this comment

          Reply to this comment

          1. mikhailnov:
            Apr 05, 2019 at 11:32 AM

            I know about this, but the question was about running Wayland on top of Xorg. In Xorg, it is possible to mount --bind X socker and set $DISPLAY variable.

            Reply to this comment

            Reply to this comment

    1. Robert Foss:
      Apr 02, 2019 at 02:33 PM

      Hey BirdZhang!

      That repo and the others are indeed open source.
      The repo you pointed out was however missing a license file, which has been fixed now.

      Thanks for pointing it out!


      Rob.

      Reply to this comment

      Reply to this comment

      1. BirdZhang:
        Apr 03, 2019 at 02:30 AM

        Sorry for the mistake, i mean the source code cannot be accessed.

        bird@ubuntu:~$ git clone https://gitlab.collabora.com/spurv/android_manifest.git .repo/local_manifests/
        Cloning into '.repo/local_manifests'...
        Username for 'https://gitlab.collabora.com':

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Apr 03, 2019 at 10:50 AM

          Hey again!

          You're correct about that too! I've now marked that repo as public (it was mistakenly listed as internal).
          Thanks for pointing it out!


          Rob.

          Reply to this comment

          Reply to this comment

          1. BirdZhang:
            Apr 04, 2019 at 03:02 AM

            Sorry again, some repos still not public
            Needed repos:
            curl -s https://gitlab.collabora.com/spurv/android_manifest/raw/master/linaro.xml |grep 'remote="collabora"'|awk '{print $3}'|awk -F'"' '{print $2}'|tr -d "\.git"|sort

            alsa-lb
            alsa-pluns
            androd-o-sensors-hal
            bm_ralloc
            devce_freedeskop
            drm
            frameworks_base
            frameworks_nave
            json-c
            lbpcaccess
            lbsndfle
            mesa
            mnjal
            pulseaudo
            sysem_b
            sysem_core
            sysem_ned
            sysem_vold

            Public repos:
            curl -s https://gitlab.collabora.com/groups/spurv/-/children.json|jq ".[] |.name" |tr -d '"'|sort

            alsa-lib
            alsa-plugins
            android-iio-sensors-hal
            android_manifest
            device_freedesktop
            frameworks_base
            gbm_gralloc
            json-c
            libpciaccess
            libsndfile
            linux
            pulseaudio

            Reply to this comment

            Reply to this comment

            1. Robert Foss:
              Apr 04, 2019 at 02:45 PM

              Thanks for listing them out, I uploaded (hopefully the last missing ones) a few hours ago.

              Reply to this comment

              Reply to this comment

  2. John:
    Apr 02, 2019 at 01:11 PM

    Instead of having to go the build process of building android and the kernel can all this packaged into flatpak?

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 02, 2019 at 02:37 PM

      Hey John,

      Yep, using flatpak for this seems very feasible to me.
      It is however beyond the scope of our current project.


      Rob.

      Reply to this comment

      Reply to this comment

  3. AOSP:
    Apr 02, 2019 at 05:55 PM

    Can the Android container run on AMD/Intel weston + mainline x86_64 Linux kernel plus ashmem and binder modules? Or does it require other patches?

    Also, video is showing only one apk. Is that a limitation? Would GSF/MicroG work in the background?

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 03, 2019 at 10:55 AM

      Hey,

      Good questions!

      The host kernel has to be built with the CONFIG_ANDROID kconfig option, which pulls in most of the dependencies you should need.

      Spurv has been run with different APKs, but has not been verified to work with multiple applications rendering at the same time.
      To be clear, multiple APKs are running in the background, but only one is rendering. There isn't a fundamental limitation about, but it hasn't been our focal point.

      Reply to this comment

      Reply to this comment

      1. Genx Ster:
        Apr 03, 2019 at 11:39 PM

        How is multiple windows sessions rendered by Wayland passed by hwcomposer on desktop ,how about integration with other host wm on rendering multiple windows instances similar to chrome os .
        As we can see it has similar feature as arc++ , does it spawn whole desktop in Android subsystem ?
        You can find such flaws when using a floating widget app in Anbox
        How about more hw peripherals supports by binding dev/* addresses or enabling better hal support layer for accessing same hardwares binded in Android subsystem.
        Thanks

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Apr 04, 2019 at 11:44 AM

          Hey Genx Ster,

          While I can't comment on ARC++, SPURV does indeed spawn an entire Android desktop subsystem.

          I can see floating widgets presenting a marginally larger challenge than running a single app in fullscreen mode,
          due to more HWComposer layers being required. This isn't something we've tested for, but it should work or at least be simple to fix.

          If you look at [1], you can see how resources are bound to the container.


          Rob.

          Reply to this comment

          Reply to this comment

  4. MarkDubya:
    Apr 02, 2019 at 07:55 PM

    It asks for a username and password when cloning the repo. I don't see anywhere to register for Phabricator. I already have a GitLab account, but I was not able to sign in with it.

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 03, 2019 at 10:56 AM

      Hey MarkDubya,

      This was pointed out by another commenter too, and has been fixed now.
      The manifest repo was wrongly marked as internal.


      Rob.

      Reply to this comment

      Reply to this comment

      1. Robert Foss:
        Apr 03, 2019 at 03:02 PM

        They all should be by now, tell me if something isn't.

        Reply to this comment

        Reply to this comment

        1. MarkDubya:
          Apr 03, 2019 at 04:04 PM

          During the repo sync, I got this:

          Fetching project device_freedesktop.git
          The authenticity of host 'gitlab.collabora.com (46.235.227.192)' can't be established.
          ECDSA key fingerprint is SHA256:FVDKBUF1Cx04+VyCF4uAUa1BgKfrKuZ3rZZNYiqvnv4.
          Are you sure you want to continue connecting (yes/no)? y
          Please type 'yes' or 'no': yes
          Please type 'yes' or 'no': yes
          Please type 'yes' or 'no': yes
          Please type 'yes' or 'no': yes
          Please type 'yes' or 'no': no
          Please type 'yes' or 'no': no
          Host key verification failed.
          fatal: Could not read from remote repository.

          Please make sure you have the correct access rights
          and the repository exists.

          Reply to this comment

          Reply to this comment

          1. Robert Foss:
            Apr 03, 2019 at 04:42 PM

            Don't use SSH if you don't have an account on the gitlab instance.

            Reply to this comment

            Reply to this comment

            1. MarkDubya:
              Apr 03, 2019 at 05:15 PM

              How do I not use SSH? I just used "repo sync -j15" per the instructions. I'm using repo 1.13.2-1 on Manjaro.

              Reply to this comment

              Reply to this comment

              1. Thomas:
                Apr 03, 2019 at 07:34 PM

                In local_manifests/linaro.xml, change `fetch="ssh://git@gitlab.collabora.com/spurv/"` to `fetch="https://gitlab.collabora.com/spurv/"`. That let me continue with syncing with everything.

                Reply to this comment

                Reply to this comment

                1. MarkDubya:
                  Apr 03, 2019 at 11:21 PM

                  Thanks, it's continuing now.

                  Reply to this comment

                  Reply to this comment

                2. Robert Foss:
                  Apr 04, 2019 at 11:52 AM

                  Thanks Thomas, I've fixed this in the repo now.

                  Reply to this comment

                  Reply to this comment

  5. Jean:
    Apr 03, 2019 at 03:45 PM

    this one is still private : frameworks_base.git

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 03, 2019 at 04:45 PM

      Good find, thanks for pointing it out.
      I'm currently uploading that repo.

      Reply to this comment

      Reply to this comment

  6. John:
    Apr 03, 2019 at 11:17 PM

    The linaro.xml manifest is broken. I think there's a space at the beginning of the xml file.

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 04, 2019 at 11:53 AM

      Hey John,

      I've fixed this in the repo now, thanks for telling me!


      Rob.

      Reply to this comment

      Reply to this comment

  7. John:
    Apr 04, 2019 at 12:02 AM

    The step to copy the file below was omitted from readme.md:
    sudo cp /usr/bin/qemu-arm-static rootfs/usr/bin

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 04, 2019 at 12:20 PM

      Hey again John,

      I actually didn't need to do this step, but rather used these instructions:
      https://wiki.debian.org/QemuUserEmulation


      Rob.

      Reply to this comment

      Reply to this comment

  8. MarkDubya:
    Apr 04, 2019 at 12:48 AM

    It got stuck here:

    From https://android.googlesource.com/platform/tools/test/connectivity
    c36d1e492..2a72edf07 master -> aosp/master

    I finally gave up & hit Ctrl C:

    error: Cannot fetch system_bt.git from https://gitlab.collabora.com/spurv/system_bt.git
    error: Cannot fetch system_netd.git from https://gitlab.collabora.com/spurv/system_netd.git
    error: Cannot fetch system_vold.git from https://gitlab.collabora.com/spurv/system_vold.git
    error: Cannot fetch mesa.git from https://gitlab.collabora.com/spurv/mesa.git
    error: Cannot fetch minijail.git from https://gitlab.collabora.com/spurv/minijail.git
    error: Cannot fetch system_core.git from https://gitlab.collabora.com/spurv/system_core.git
    error: Cannot fetch frameworks_native.git from https://gitlab.collabora.com/spurv/frameworks_native.git
    error: Cannot fetch drm.git from https://gitlab.collabora.com/spurv/drm.git
    aborted by user

    How large is it supposed to be after the repo sync? the folder is almost 40GB right now.

    Reply to this comment

    Reply to this comment

    1. BirdZhang:
      Apr 04, 2019 at 03:07 AM

      repo init -u https://android.googlesource.com/platform/manifest -b android-9.0.0_r10 --depth=1


      repo sync -c --no-tags --no-clone-bundle -j8

      Reply to this comment

      Reply to this comment

    2. John:
      Apr 04, 2019 at 10:06 AM

      Yeah, it asks for a user credentials for those repositories.

      Reply to this comment

      Reply to this comment

    3. Robert Foss:
      Apr 04, 2019 at 12:22 PM

      Hey MarkW,

      I would expect the finished sync'd and built repo to be about 100GB.

      As for the errors you are seeing, they are my fault, and have been fixed.
      They were due to me not wanting to depend on any external repositories.

      Rob.

      Reply to this comment

      Reply to this comment

  9. Marcos Dione:
    Apr 04, 2019 at 09:58 AM

    Is it possible to fake certain values? Like Phone number, IMEI, etc? I would definitely like to run WhatsApp on my desktop...

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 04, 2019 at 02:46 PM

      Hey,

      Most likely, you have access to the Android source code after all, but how is a different question.


      Rob.

      Reply to this comment

      Reply to this comment

  10. MarkDubya:
    Apr 04, 2019 at 04:41 PM

    I finally finishing syncing, now I'm getting an error building:

    $ make -j12
    ============================================
    PLATFORM_VERSION_CODENAME=REL
    PLATFORM_VERSION=9
    TARGET_PRODUCT=spurv
    TARGET_BUILD_VARIANT=eng
    TARGET_BUILD_TYPE=release
    TARGET_ARCH=arm
    TARGET_ARCH_VARIANT=armv7-a-neon
    TARGET_CPU_VARIANT=generic
    HOST_ARCH=x86_64
    HOST_2ND_ARCH=x86
    HOST_OS=linux
    HOST_OS_EXTRA=Linux-5.0.5-1-MANJARO-x86_64-Manjaro-Linux
    HOST_CROSS_OS=windows
    HOST_CROSS_ARCH=x86
    HOST_CROSS_2ND_ARCH=x86_64
    HOST_BUILD_TYPE=release
    BUILD_ID=PPR2.181005.003
    OUT_DIR=out
    ============================================
    [1/1] out/soong/.minibootstrap/minibp out/soong/.bootstrap/build.ninja
    [44/45] glob prebuilts/ndk/stl.bp
    [77/77] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja
    out/build-spurv-cleanspec.ninja is missing, regenerating...
    out/build-spurv.ninja is missing, regenerating...
    [154/948] including external/drm_gralloc/Android.mk ...
    external/drm_gralloc/Android.mk:43: warning: invalid GPU drivers: etnaviv imx
    [198/948] including external/libdrm/Android.mk ...
    external/libdrm/libkms/Android.mk:19: warning: invalid GPU drivers: etnaviv imx
    [578/948] including system/sepolicy/Android.mk ...
    system/sepolicy/Android.mk:79: warning: BOARD_SEPOLICY_VERS not specified, assuming current platform version
    [948/948] including tools/tradefederation/core/Android.mk ...
    external/alsa-lib/Android.mk:42: warning: overriding commands for target `out/target/product/spurv/system/usr/share/alsa/alsa-conf'
    build/make/core/base_rules.mk:412: warning: ignoring old commands for target `out/target/product/spurv/system/usr/share/alsa/alsa-conf'
    external/alsa-lib/Android.mk:46: warning: overriding commands for target `out/target/product/spurv/obj/ETC/alsa-conf_intermediates/alsa-conf'
    build/make/core/prebuilt_internal.mk:507: warning: ignoring old commands for target `out/target/product/spurv/obj/ETC/alsa-conf_intermediates/alsa-conf'
    [ 99% 703/704] glob tools/tradefederation/core/atest/**/*.py
    [ 0% 14/49152] build out/target/common/obj/all-event-log-tags.txt
    FAILED: out/target/common/obj/all-event-log-tags.txt
    /bin/bash -c "build/make/tools/merge-event-log-tags.py -o out/target/common/obj/all-event-log-tags.txt frameworks/base/core/java/android/app/admin/SecurityLogTags.logtags frameworks/base/core/java/android/content/EventLogTags.logtags frameworks/base/core/java/android/net/EventLogTags.logtags frameworks/base/core/java/android/os/EventLogTags.logtags frameworks/base/core/java/android/speech/tts/EventLogTags.logtags frameworks/base/core/java/android/webkit/EventLogTags.logtags frameworks/base/core/java/com/android/internal/app/EventLogTags.logtags frameworks/base/core/java/com/android/internal/logging/EventLogTags.logtags frameworks/base/core/java/com/android/server/DropboxLogTags.logtags frameworks/base/core/java/org/chromium/arc/EventLogTags.logtags frameworks/base/packages/SettingsProvider/src/com/android/providers/settings/EventLogTags.logtags frameworks/base/packages/SystemUI/src/com/android/systemui/EventLogTags.logtags frameworks/base/services/core/java/com/android/server/EventLogTags.logtags frameworks/base/services/core/java/com/android/server/am/EventLogTags.logtags frameworks/ex/common/java/com/android/common/GoogleLogTags.logtags frameworks/native/services/surfaceflinger/EventLog/EventLogTags.logtags frameworks/opt/telephony/src/java/com/android/internal/telephony/EventLogTags.logtags packages/apps/QuickSearchBox/src/com/android/quicksearchbox/EventLogTags.logtags packages/apps/Settings/src/com/android/settings/EventLogTags.logtags packages/apps/TimeZoneUpdater/src/main/com/android/timezone/updater/EventLogTags.logtags packages/providers/CalendarProvider/src/com/android/providers/calendar/EventLogTags.logtags packages/providers/ContactsProvider/src/com/android/providers/contacts/EventLogTags.logtags packages/services/Telephony/src/com/android/phone/EventLogTags.logtags system/bt/main/../EventLogTags.logtags system/core/liblog/event.logtags system/core/libsysutils/EventLogTags.logtags system/core/logcat/event.logtags system/core/logd/event.logtags system/core/storaged/EventLogTags.logtags"
    File "build/make/tools/merge-event-log-tags.py", line 51
    except getopt.GetoptError, err:
    ^
    SyntaxError: invalid syntax
    [ 0% 16/49152] target Java source list: apache-xml
    File "build/make/tools/normalize_path.py", line 25
    print os.path.normpath(p)
    ^
    SyntaxError: invalid syntax
    [ 0% 25/49152] target Prebuilt: sdk_v21 (out/target/common/obj/JAVA_LIBRARIES/sdk_v21_intermediates/classes.jar)
    ninja: build stopped: subcommand failed.
    09:38:59 ninja failed with: exit status 1

    #### failed to build some targets (02:26 (mm:ss)) ####

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 05, 2019 at 01:41 PM

      Hey Mark,

      I haven't encountered this issue before.

      I think the error looks like an external dependency being bad.
      Maybe your python version is the wrong one.

      File "build/make/tools/merge-event-log-tags.py", line 51
      except getopt.GetoptError, err:
      ^
      SyntaxError: invalid syntax
      [ 0% 16/49152] target Java source list: apache-xml
      File "build/make/tools/normalize_path.py", line 25
      print os.path.normpath(p)
      ^
      SyntaxError: invalid syntax
      [ 0% 25/49152] target Prebuilt: sdk_v21 (out/target/common/obj/JAVA_LIBRARIES/sdk_v21_intermediates/classes.jar)
      ninja: build stopped: subcommand failed.
      09:38:59 ninja failed with: exit status 1

      #### failed to build some targets (02:26 (mm:ss)) ####

      Reply to this comment

      Reply to this comment

      1. MarkDubya:
        Apr 05, 2019 at 03:04 PM

        How is my python version "bad"? I'm using python 3.7.3 and also have python2 2.7.16. Perhaps you should list the dependencies in your README.

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Apr 05, 2019 at 03:10 PM

          It probably isn't, but this is an error I don't recognize and haven't encountered,
          so I'll have a hard time fixing it for you.

          If you do find a solution, please tell me.

          Reply to this comment

          Reply to this comment

      2. Marcos Dione:
        Apr 06, 2019 at 09:35 AM

        It's running python2 with python3. Just change the first line so it uses python2 instead of the system's default. Something like:

        #! /usr/bin/python2

        or:

        #! /usr/bin/env python2

        Reply to this comment

        Reply to this comment

  11. Joel Isaacson:
    Apr 04, 2019 at 08:43 PM

    Coincidentally, we are working on a technology similar to SPURV. Unlike SPURV which runs locally, ours is a Cloud-Client technology in which a large number of containerized Android instances run in the Cloud. Graphical rendering is performed on the Client. The remote rendering is performed by sending compressed rendering commands (OpenGL ES) from the Android instances in the Cloud to the thin client where the rendering is performed. Here is an overview paper (http://kvm.ascender.com/aic_overview.pdf) and video
    (https://tinyurl.com/yy9vxs66).

    Reply to this comment

    Reply to this comment

    1. Philippe:
      Apr 05, 2019 at 03:10 PM

      Aah, where can we find the code?

      Reply to this comment

      Reply to this comment

      1. Joel Isaacson:
        Apr 07, 2019 at 02:56 PM

        To open source the code and create the infrastructure necessary for it to move forward in the best way possible, we require resources. I can be reached at joel@ascender.com

        Reply to this comment

        Reply to this comment

  12. Paulo:
    Apr 05, 2019 at 12:42 AM

    I wish you all the best with this project, I believe it to be something that Linux and open source desperately need.

    Is it your goal to have something functioning like Bluestacks? In example, will the user be able to run arm apks in a x86 pc, will the apks be fully functional at their best performance, will there be a key mapper for gaming, will it be possible to install gapps and so on?

    And do you intent to have a noob friendly install for the masses, something like a flatpak, snap package or an appimage?

    If so and with the recent major developments in WINE/Steam Play and Lutris, this could be the beginning of a paradigm change in order to bring Linux and open source to the general users and the masses.

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Apr 05, 2019 at 01:46 PM

      Hey Paulo,

      So gaming isn't really our intended application, but it does place emphasis
      all of the same bottlenecks & features that we are targeting.

      We're currently not intending to make this a end-user application
      but rather a developers tool and for embedding into products.

      About a paradigm shift, this work still requires the host machine to run Linux,
      which is not what most people use.

      Reply to this comment

      Reply to this comment

  13. AOSP:
    Apr 05, 2019 at 04:32 PM

    Starting compile on Archlinux. So far many issues

    On Archlinux it requires ncurses5-compat-libs from AUR.
    /usr/bin/python needs to be removed and linked to /usr/bin/python2
    arm architecture in BoardConfig.mk needs to be changed to x86_64
    external/alsa-lib/src/pcm/pcm_local.h and external/alsa-lib/src/control/control_shm.c need to have added
    external/pulseaudio/src/pulsecore/core-util.c needs #define __USE_GNU 1 before

    Also, the captcha on this site is very annoying. If there is an intention to provide some support or bugfixing for this project, it should be cloned to gitlab or github so people can open issues there.

    Reply to this comment

    Reply to this comment

    1. Marcos Dione:
      Apr 06, 2019 at 09:42 AM

      I wouldn't change the system's python like that. Just edit the failing files like I posted above. Cheers.

      Reply to this comment

      Reply to this comment

    2. Robert Foss:
      Apr 09, 2019 at 02:36 AM

      Hey AOSP,

      Very nice!

      This project is alive (albeit paused this month) within Collabora, and will likely be resumed soon.
      I added a 'What comes next?' section, describing what we'd like to look at next.

      Reply to this comment

      Reply to this comment

  14. Niall:
    Apr 06, 2019 at 06:51 PM

    Trying to build on Arch Linux, ninja: error: 'out/target/product/spurv/system/bin/app_process32', needed by 'out/target/product/spurv/system/bin/app_process', missing and no known rule to make it
    17:51:13 ninja failed with: exit status 1

    Reply to this comment

    Reply to this comment

  15. Genx Ster:
    Jun 06, 2019 at 05:05 PM

    Hey @Robert Foss Do you have a compiled one spruv project , my current bandwidth/machine is too limited to compile one.
    Thanks

    Reply to this comment

    Reply to this comment

      1. Genx Ster:
        Jun 06, 2019 at 05:39 PM

        arch ??
        X86 or x86_64 or arm64 ...

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Jun 06, 2019 at 05:43 PM

          This image and the blogpost it was made using targets an iMX6 devboard.

          Reply to this comment

          Reply to this comment

      2. Genx Ster:
        Jun 06, 2019 at 05:43 PM

        Got that , thats an arm based sbc but i need an x64 img

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Jun 06, 2019 at 05:45 PM

          Unfortunately I don't have one laying around. This work is however all very muxh x86 compatible.
          But it hasn't been used on x86 yet, so you would have to get your hands dirty I'm afraid.

          Reply to this comment

          Reply to this comment

          1. Genx Ster:
            Jun 06, 2019 at 05:50 PM

            the aosp source size itself is 12-15 gigs , imo and my bandwidth is limited to 1gb per day + building that thing on anyhow downloading on my machine even after getting dirty for hacks for x86 sku would take several days , lol

            Reply to this comment

            Reply to this comment

            1. Robert Foss:
              Jun 06, 2019 at 07:13 PM

              Yeah, building AOSP is always quite the endeavor.

              If you still want to make it happen you could rent a machine on AWS of GCE.

              Reply to this comment

              Reply to this comment


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

ROCK Pi and an easy place: Panfrost & Wayland on a Rockchip board

06/08/2019

Ongoing work on the reverse-engineered Panfrost OpenGL ES driver for Arm Mali GPUs has turned the RK3399 SoC into a very attractive platform…

What's new in OpenXR 1.0 & Monado?

02/08/2019

As part of its unwavering commitment to open source and open standards, Collabora is proud to be part of bringing the recently-released…

Zink: Summer Update & SIGGRAPH 2019

25/07/2019

There's been quite a few updates to Zink, an OpenGL implementation on top of Vulkan, since I last wrote about it. Here's an overview of…

GStreamer in Oslo

18/07/2019

A little over a month and a half ago, Collaborans including Aaron Boxer, George Kiagiadakis, Guillaume Desmottes, Stéphane Cerveau and myself…

GNOME meets Panfrost

26/06/2019

In my last Panfrost blog post, I announced my internship goal: improve Panfrost to run GNOME3. GNOME is a popular Linux desktop making heavy…

Using dummy-hcd to play with USB gadgets

24/06/2019

Dummy_hcd which consists of a software-emulated host controller and a UDC chip. In other words, this means you can play with USB gadgets…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2019. All rights reserved. Website sitemap.