This could be really useful for Android. For example, continuous integration services like Circle CI are completely useless for UI automation tests because they don't expose virtualization infrastructure necessary to run the fast x86 emulator. The ARM one is unusably slow (even with dozens of lines of code by me to try to keep the screen on and unlocked while tests that run in 10 seconds on a dev machine with x86 plod through taking over half an hour on ARM).
Circle has mentioned in discussions that the virtualization limit will never be fixed because it is due to them running on Google's cloud services that don't support it.
It's not exactly ideal for CI. We had to run uiautomator tests on Jenkins to get sensible real-world device coverage. On top of that these were a pain to maintain as each device required things to be done a little differently. Not to mention the hell we had doing CI on older devices with 4.4.4.
Can someone explain how badly `snap install --classic anbox-installer` might mess up my development machine? Can I expect uninstall to properly clean up?
IIUC installing the snap should be easily reversible, but it only installs an installer :). The installer then does some much more intrusive stuff, It has to install kernel modules for ashmem and binder.
Can't really blame the devs, it's easy to see how this would be a hard thing to package via normal techniques.
It's already using containers (LXC) for running the actual Android system. The rest of the package contains kernel modules and udev rules, which aren't suitable for containerization.
Sort of related: I think Android should consider switching to using cgroups for each application, rather than a separate user account. This will bring it more in line with the mainline kernel and maybe we can see some enhancements there.
Gee, I had kinda hoped/expected that was the case already. Aren't iOS apps sandboxed like that? Sadly, I think many exploits involve chaining until you get to a defect in the kernel -- from which a cgroup namespace wouldn't help much.
It's not a bad idea, but why would that bring them closer to the upstream kernel? UIDs aren't exactly special; are they doing some extra user separation?
Yah, id try to explain but I'll get downvoted for not bring completely correct. It's 'different', there are a bunch of great blog posts on it. Iirc the biggest problem is Google's patches are pretty useless to the rest of the Linux community because the security model is so strange
This is pretty cool, but the advent of Android Things might've rendered it obsolete. My understanding is you can run a custom Android Things image on a Raspberry Pi 3, and get access to the full Android OS, along with developer niceties like adb for pushing APKs.
I'm not sure it's really comparable to Android Things... you can run this in an LXC container on your desktop. With Android Things, unless I've missed something, you need to start by getting a Development Board from the supported hardware list.
Furthermore, Android Things is designed to run just one application on the whole machine, whereas Anbox is for running Android apps in a container within a multitasking environment.
This is cool. I guess something similar might be coming from google as part of unification between android and chrome OS. However this is still very useful as it can exist outside chrome OS ecosystem.
This is really cool from a technical perspective, but what's the use case? I can't think of a single Android app that I use that doesn't have an equivalent desktop/web app that's optimized for a mouse and keyboard. I can't imagine the UX nightmare of using touch-optimized apps on a regular PC.
> I can't think of a single Android app that I use that doesn't have an equivalent desktop/web app that's optimized for a mouse and keyboard.
I can. E.g. my phone settings manager, my TV provider's remote app, my main screen of multiple widgets, my local TV station's weather app w/ notifications, etc. Also, in many cases for web apps w/ mobile app equivalents, the latter are easier to use and snappier. Finally, though less useful, this can give an app developer a sandbox in which to embed his app upon distribution and be able to target Android and Linux assuming the app is simple.
> I can't imagine the UX nightmare of using touch-optimized apps on a regular PC.
You'd be surprised. Android has full mouse and keyboard support - you can click on buttons, tab between text boxes, use scroll gestures... it's not perfect (and some apps are awful) but I've been very surprised by how much I can do.
If you can debug in this, it's got to feel a lot faster than the emulator. Though I admit I haven't used the emulator in so long that I don't know if they ever fixed how slow it was.
I'm not sure you need a use case for this to be a sensible addition to the tools we have in the box.
IMHO if this machine is linux, and that machine is linux, and both machines are fully open, then why can't you run this app on that machine? Because reasons, that's why... no more!
I've been interested in something like this since Spotify pulled all support for their cross-platform libspotify library and left us with just their iOS and android SDKs. Nothing I could see specifically mentions audio support but surely it's a given.
WhatsApp. I have several phone numbers, despite having just one phone - and I need separate WhatsApp accounts for each, but the official (essentially, only) client insists on only being connected to one.
+1
WhatsApp is the only reason I keep an Android phablet with data only plan which I would happily get rid of since I do everything on a laptop or small netbook when possible.
I know about the WA web client, but it doesn't solve the problem as it requires the phablet to be on, connected and not in sleep mode which is a huge limitation.
I wonder whether this could work on Sailfish OS? Currently there is a similar library called Alien Dalvik, but which is proprietary and can only run on phones that Jolla officially produces, not ports to other hardware.
I wonder whether this could be used as a simple way to get an Android env for Qt development? Last time I did Qt dev for mobile the biggest headaches were trying to get the Android SDK and NDK configured and setup in a way that actually worked with Qt :-s
(Similar-ish thought for React Native, although it was much easier than Qt somehow (so much so that originally I was planning to do the project in Qt and changed to React Native because everything was up and running much faster).)
Last time I tried Qt for android, the problem wasn't setting up development kits, but rather, it didn't support the x86 android target in order to run the fast emulator.
In any case, this is not about development environments, this is about running android in a chroot jail likr environment directly on linux.
Is this running on ARMv7-based boards yet, or only on x86 machines? The former would be much more useful for running proprietary Android apps with a native component.
You might be surprised how many Android apps work on x86 too. Either they are "fat" (have libraries for multiple ABIs in the .apk) or the Play Store has multiple versions, and delivers you the one for your platform.
Edit: however, the last FAQ mentions there's a system image for armhf so you might be in luck anyway :)
If nothing else, it's probably worth looking into integration with qemu user mode emulation, which already allows execution of ARM binaries on x86 platforms
Yes, this is generally possible. However Google doesn't allow anyone to ship its applications as long as the device is not certified and the vendor didn't sign an agreement with Google.
The Anbox project does not have any interest in shipping the Google Play store and we're not allowed to do so. We may add an easy way for our users at a later point which allows easy distribution of Android applications suited for the Anbox runtime environment."
But anbox is already running a flavor of AOSP, which is android without google (unless you meant android without google code, in which case you will have exactly nothing to run). AOSP can entirely be built from source, everything is Apache2-licenced, and it does not contain or require the gapps. Now you can add most gapps APIs (in order to make apps that rely on them work) through the microg project, or you can install the official google services using opengapps.
If there's hardware-accelerated video decoding for DRMed streams exposed to the guest OS then it should. That is if there's a x86 supporting APK for each one too.
Circle has mentioned in discussions that the virtualization limit will never be fixed because it is due to them running on Google's cloud services that don't support it.
They do seem to support LXC, however: https://circleci.com/docs/enterprise/config/