Anbox on pinetab

[saulrh]

Spent a good chunk of today attempting to get anbox running under mobian (Linux thalia 5.7-pinetab #1 SMP PREEMPT Fri Sep 11 11:37:38 UTC 2020 aarch64 GNU/Linux) because why not. A log of my progress:

• Nobody's built a snap for arm64 so I can't do that.
  
• Attempted to build anbox from source and actually managed it, but couldn't use it because all the plumbing (e.g. systemd and dbus stuff) is contained in the snapcraft yaml which is used to build systemd units when the snap is built so make install produces roughly one-third of a functioning installation.
  
• Attempted to build a snap myself but it failed because snapcraft builds in a container using multipass but multipass uses qemu's default --machine handling which is unpopulated on arm64 so it complains and bails out. Can't use the --destructive-build option, which skips the containerization, because it just blows up due to a library version mismatch. Also, snaps don't support cross-compilation. Like, at all.
  
• Finally decided to just ignore apt's attempts to tell me that anbox wasn't available for my system and started using curl and dpkg to install random debs from other releases. Eventually found this one that appears to have installed mostly right: http://http.us.debian.org/debian/pool/co..._arm64.deb.
  
• anbox-container-manager.service wouldn't start because it was attempting to modprobe ashmem_linux and binder_linux, which don't exist any more because they're now (respectively) in-tree and obsolete. /proc/config.gz has both CONFIG_ASHMEM=y and CONFIG_ANDROID_BINDER_IPC=y, so I just edited /lib/systemd/system/anbox-container-manager.service to remove the modprobes. That got anbox-container-manager.service enabled and started. However, this doesn't yet prove anything because the container manager doesn't start the container until a request is received from the session manager, so we haven't actually tried talking to lxc yet.
  
•  anbox session-manager also complained about not having ashmem or binder. It turned out that it was looking for binder by just attempting to blindly open /dev/binder, which has been superseded on recent kernels by binderfs. I "fixed" this by manually creating a binderfs and then symlinking the device in where anbox was looking: mkdir -p /dev/binderfs ; mount -t binder binder /dev/binderfs ; ln -s /dev/binderfs/binder /dev/binder. This got the session-manager to at least do something, though it immediately failed out because the container manager can't start a container.
  

Current status:

Code:

mobian@thalia:~$ anbox session-manager
[ 2020-09-19 12:21:17] [client.cpp:49@start] Failed to start container: Failed to start container: Failed to start container
[ 2020-09-19 12:21:17] [session_manager.cpp:152@operator()] Lost connection to container manager, terminating.
[ 2020-09-19 12:21:17] [daemon.cpp:61@Run] Container is not running

Logs for anbox-session-manager.service are clean, so I have to hunt down the logs for the attempt to actually start the container. Either way, I called it a night there. Probably going to turn out to be an obvious-but-unfixable showstopper in lxc-on-arm64 or something equally obnoxious. Or, like, dbus blowing up for no reason. Maybe I'll keep tearing out attempts to modprobe unnecessary kernel modules until it all works. Or I'll just try arch! Who knows? The me of tomorrow, probably.