Development testers for Anbox
@brywilson Can you give this kernel a try http://cdimage.ubports.com/anbox-images/anbox-boot-turbo-test.img
@brywilson I only did what is recommended on this page, using the anbox-boot-turbo-test.img. I had previously tried to install anbox and it didn't work (the previous anbox-boot-turbo.img kernel) so an anbox android image was already on my device so
anbox-tool installdidn't work. I then used
anbox-tool upgradeand then everything worked. Regarding logging into the container, yes, I use the
sudoway. Yes, there are a lot of debugging messages flooding the screen but in spite of that I type the commands (thanks @Alkis for the code above)and then I hit enter and this is how I got the apk(s) installed.
Somehow my anbox on OPO is still not runing even after few restarts.
Is there any option to start it via terminal?
phablet@ubuntu-phablet:~$ anbox-tool status Kernel: OK System: OK Enabled: YES Running: NO
Thanks muchly to @mariogrip @Stefano and @mihael for your wonderfully quick replies there! I already had the anbox-boot-turbo-test.img installed and ended up trying the advice given by @mihael and using the "sudo lxc-console..." command and then the "cd data && pm install app.apk" commands whilst the debugging was still running...
And it worked! Although my celebrations were shortlived, after receiving the "App won't run without Google Play services etc etc" and the app then crashing
Despite knowing that it would be too easy a solution, I just tried installing google-play-services.apk - and now my installed apps crash instantly
@tricky In my very poor understanding, somehow the anbox-tool does not reflect the state of the android container. So, the android apps can still work even though
anbox-tool statussays that is not running. For me, the true way to find if the android container is not running is to try to login into it with
sudo lxc-console -ndefault -P /home/phablet/anbox-data/containers -t0- when it's running I can login and when it's not then it says so. Why would I need that? - because if an android app does not start then I need to find if it's because of the android container not running, in which case I don't know how to start it except by a reboot of the phone
Maybe @mariogrip could help us with the command to start the android container?
@brywilson In order to use Google Play Services you would have to use something like this: https://www.linuxuprising.com/2018/07/anbox-how-to-install-google-play-store.html (but it would most certainly require adapting at least to ARM + I have no idea what the script does, haven't looked at it). So simply said you can't use some things without installing GApps and you can't install GApps without some tweaking.
Well, I've had a wee play around - thanks @zubozrout for the Google Play tips. Whilst I love the idea of Anbox - having your Ubuntu Touch cake and eating it - my major use for it (as a 16.04/devel daily user!) was to install Android apps until UT ones became fully functional again. Primarily, this was to try and install Android browsers (using FDroid) until the UT stock browser or browser next were upgraded such that I could access some of my more frequently browsed websites. However, I couldn't get any of the Android browsers to work - they installed but then hung whilst trying to access a URL.
However, I did install DAVDroid (a CalDav sync tool) and successfully sync'd (or is it sunk?) my nextCloud calendar to the Anbox Calendar! I then I hilariously noticed that a recent upgrade (was it today's?) actually fixed the UT stock calendar - so, I of course immediately deleted the now unnecessary DAVDroid app Point in case!
I also installed the nextCloud Notes app from FDroid - and it worked perfectly with my nextCloud server!
Which got me thinking as to whether we might have a page somewhere on the UBports website, dedicated to those Anbox apps which successfully install or not. I'm thinking it might be a little like the WINE-software compatibility pages, where apps get bronze, silver and gold ratings depending upon the app's useability. Just a thought.
I was also thinking - slightly snobbishly - that the presence of those Android icons in my Apps Scope made me feel a little unclean. I know UT is lagging slightly(!) behind iOS and Android for apps - and Anbox fills an apparently necessary gap - but that doesn't mean I want them right there on my UT Apps Scope Any chance - and this may already be in the pipeline - we might be able to have a dedicated Anbox Scope?
Finally - and for completeness' sake (and not that I'm considering it now) - but how do I go about totally removing Anbox from UT?
@mihael and @Stefano before trying myself again to test Anbox with the updated Turbo image, could you kindly confirm to me which issues have been resolved according to the following Anbox issue filed on Github?
@matteo I wrote in that github issue as well: IMEI, SIM and Camera work. I still have to check GPS. There is a battery drain which I will detail bellow.
There is a constant battery drainage which occurs now after installing anbox. @mariogrip Could it be something related to the kernel? - like maybe it doesn't know how to go into standby or something... It is not related to using the phone or having the android apps on or even the android container on - it is the same drainage even when the container is not on and I cannot start the android apps.
Hey @mihael, that's interesting - I'm on a Meizu Pro 5 (16.04/devel) with Anbox installed - and my battery profile is seemingly utterly unaffected. I fully charged three hours ago - and I'm at 98% now.
Although, I did disable anbox (with "anbox-tool disable")...
On N5 I recognized: Installing System updates seem to cause the reinstallation of the native kernel. This causes a disfunctionallity of anbox and heating of your device (100% CPU). I recommend to disable automatic System updates.
@mihael My OPO is not affected by this issue. One of my Anbox apps has been running for ~24 hours and my battery statistics looks the same as without Anbox installed.
I also wanted to add that my battery life in Hammerhead with the custom kernel and anbox seems to run just fine. No battery drain, everything is normal. Happy with the results because this was one of the first things that I was most worry about it but so far so good.
anbox-tool disabledoes the trick! Thanks! The battery consumption is now back to normal...
@mihael that's a great news! Thank you for reporting me also on Github, I appreciate.
Nonetheless, I'll wait a little bit more prior to install Anbox again, because this time I'd like to be sure not having big surprises
@mihael Did you install any android apps? since android allow background services so they would run in the background, this is something we can make more strict later (with options). Since my testing running "just anbox" without any extra apps installed is good.
@mihael anbox disable stops all anbox services, so if that work we can rule out that the kernel is an issue. I would assume its an android app stealing your battery, but if you don't have other apps then per-installed please tell me then i need to dig into it.
 Anbox consists of two always running services, one root service that creates and managers the container itself (anbox-container) and one running as users acting as the fronted providing the container with graphics windows, audio, scaling etc (anbox-session).
@mariogrip Thank you for all the help! Yes, I installed WhatsApp and Viber. Do you thing the battery drainage might be because of these two apps?
anbox-tool disablestops the battery drainage so is definitely not the kernel's fault.
I was misled by the situations when android apps would not start (thinking this is because of the container not running) but the battery drainage being still constant. Later I discovered that the services can be stopped with
anbox-tool disableand then battery drainage stops.
There is still this question: sometimes the android apps would not start and I cannot login into the container and then my only solution is to restart the device. Is there a command to restart the android services or the container or something?
Again, thank you!