@joao-0 Apologies, wish I had a better way of helping you install it. If you've got my boot.img, and have TWRP on your device, you could always flash it that way.
Or you can boot to Fastboot/bootloader, and issue a
fastboot boot <path/to/boot.img> for temporary testing,
or
fastboot flash boot <path/to/boot.img for permanent installation
from a computer
@joao-0 Ah, if you've already done the Flo installation, then open a terminal and do sudo start bluetooth-touch-flo
If you want this working on every boot:
sudo mount -o remount,rw /
sudo cp /etc/init/bluetooth-touch-flo.conf /etc/init/bluetooth-touch-deb.conf
This is because despite running a Flo kernel, the hardware still reports it's a deb, and the ubPorts image appears to be missing the upstart item for the deb, and is missing a redirect from bluetooth-touch to just use the flo version regardless.
@joao-0 There is not, I do not put out video tutorials. If you really want to run the Flo software, run the UBports installer and then follow the instructions for if your device wasn't detected and select the Flo. Of course, this means you'll lose LTE connectivity as the Flo image does not support it, for that, you need to Frankenstein the device with a Deb image and Flo kernel.
Because of how sensitive that proceedure is, I advise against YouTube tutorials due to many possibilities, however I'll use the most prominent one from another homebrew scene as my reason why I do not do videos, over in the Nintendo3DS homebrew scene, a dude bricked people's consoles because he uploaded a "One Size Fits All" package with a video, containing device specific files that wouldn't work when put into another console.
If you want a decent Deb experience, download the boot.img in my OP, fastboot up TWRP, and then install the boot.img into the boot partition using it. Reboot. Done.
If you are wanting to use this kernel with a Flo product, simply do the same things. Both Nexus 7 models use the same kernel anyway.
@a8ksh4 By chance are you using any Slimport cables? I'd like to have someone test that Slimport is still functioning in the current Dev branch as it had stopped after an update for me despite using the same kernel, which had more or less fixed Slimport previously after switching over to using the Flo kernel config instead of the Deb kernel config.
As for Anbox, that's definitely not typical, I wonder if something has changed in how it's supposed to be installed since I wrote those instructions. As I was able to install it, but have a hard time getting it running consistently.
One problem I noticed is that there seems to be a lack of firewall rules that are added, where the script anbox-bridge is supposed to handle them. It doesn't seem to function right on our devices and if you make the anbox-bridge script return true, it should get you past "Job failed to start". There's an old Anbox issue ticket that applies here: https://github.com/anbox/anbox/issues/443 and is linked to the ubports Anbox ticket: https://github.com/ubports/anbox/issues/42 both are applicable because even if Anbox starts properly, the firewall isn't initialized properly and thus anbox has no internet functionality.
@Brianrh If it runs Android, can I have you install a terminal emulator and check: https://forum.xda-developers.com/t/trying-to-recreate-entire-partition-table-for-nexus-7-2013-flo.3881263/post-78581593 , especially if you're on 17.1, pretty sure 17+ use the FloX packages which require the repartitioning.
If your results don't match up, then you may need to find the "back to stock partitioning" recovery package from the Flo forums over at XDA.
Not sure if Restock returns it to the stock partition layout or not, FloX was very recently introduced iirc.
Edit: Sorry, replied to the wrong user at first.
@thomas-k8s Nah, you lose the native XMir windowing with that. I'm more partial to how we did it in the days before libertine's release back in 15.04 (still chroot, not libertine's proot which seems more restrictive, but using XMir with matchbox-window-manager to provide some semblance of window managment)
Nowadays, I'm looking into something similar, but using the Gentoo Prefix in place of the chroot, so it runs unprivileged. Obviously will generate a LOT of I/O so if anyone else goes this way, I highly recommend running the bootstrap as far as it will let you using an NFS root mounted into the home directory somewhere (mine is .local/system) and then copy it to device and finish the bootstrap using an NFS-mounted TMPDIR (because bootstrap will only let you go so far before portage tells you that it needs root permissions for some reason when bootstrapping straight to an NFS shared folder)
@emphrath No problem, I've tried a lot of things that most people would find "useless" under ubPorts while working to make my trusty Nexus 7 a portable workstation. I've been tempted to add WINE to my setup again, but I don't want to deal with setting up an i386 chroot running on the device (since LXC doesn't function correctly for me, can't create LXC containers, oddly the Android container works fine).
In case I didn't mention it previously, yes, it requires qemu-user-static installed and you have to have an i386 chroot to install and run WINE/32.
@emphrath Actually due to something involving proot (the application that facilitates the unprivileged chroot), WINE (and QEMU) refuses to run with a segmentation fault.
Running WINE under XMir is relatively simple, though it does require the system image to be writable. You'd need a kernel with binfmt_misc support, install qemu-user-binfmt and wine:i386 from the winehq repo. Then you just need a XMir wrapper (I think libertine-xmir is one), a script to start it all, and a .desktop shortcut to point the --desktop_file_hint argument to.
I did a write-up on running applications with Xmir without Libertine under Vivid a while back over on XDA-Developers (found here under the "old method" heading), go crazy!
Personally, I'm working on compiling a Gentoo Prefix so that I don't have to make system image changes just to have applications outside a Libertine container.
@alan_g You are quite right about KVM being missing (iirc, it can be enabled in the kernel configuration for, at least to my knowledge, 3.4.0+), however QEMU Usermode emulation runs quite nicely. Obviously not helpful if someone wants to run a full guest OS, but it works well for say, running WINE-x86 under Ubuntu Touch as long as you have binfmt support enabled in the kernel.
@flohack cool, thanks for the reply anyway though!.I'm trying to recompile the Android system image as Halium-7.1 but my system.img is too small, so I'm waiting on it to transfer to my PC for resizing.
Hopefully my current list, observations and efforts eventually provide some help for us to bring the Deb up to par with Flo.
@totalsonic I'd like to try for that, Honestly I'd like to use my Nexus 7 Deb as a cellular workstation, even have the SlimPort dock for it if the problems with SlimPort can be figured out.
If the kernel helps, please feel free to help contribute to the issue list and post any workarounds you may find.
@paultimperley I have a fix/workaround for Bluetooth, not sure about telephony issues as I only have a data SIM I can use for this device. Come on over to: https://forums.ubports.com/topic/6056/nexus-7-lte-general-bugs-problems at least for a bluetooth workaround.
@sbearg At the moment, the best way to fix the bluetooth issue is to flash a ubPorts compatible 'flo' model kernel (doesn't affect LTE connectivity in any way, and the system actually runs smoother on the deb)
After flashing a 'flo' model kernel, you then have to make a tiny change to the rootfs and copy /etc/init/bluetooth-touch-flo.conf to /etc/init/bluetooth-touch-deb.conf
After rebooting with both of these conditions met, bluetooth works just as well as on the flo.
EDIT: I can provide a decent kernel image for testing with, it also includes the drivers needed for Anbox and a working zRAM driver (which needs some extra configuration to make usable) which I compiled earlier today, am planning to release my kernel source tree shortly: https://1drv.ms/u/s!AqACoL07fxpWp8gGGF_GTmO8f-tCKw?e=uAKxV1
(More information over here in this topic: https://forums.ubports.com/topic/6056/nexus-7-lte-general-bugs-problems)
@doniks I don't believe I did. The Flo worked flawlessly with Slimport, had the right screen resolution and all. They're using the same kernel, so the Slimport driver (drivers/misc/anx7808) shouldn't be the issue either.
Bluetooth can be done by remounting as rw and copying /etc/init/bluetooth-touch-flo.conf to /etc/init/bluetooth-touch-deb.conf after updating the kernel to a "flo"-based one, unfortunately copying the upstart unit alone isn't enough to make bluetooth start. (It might be worth me continuing my custom kernel project just for the deb)
I haven't tested Camera yet, I'll check that here in a little bit after I get my setup back up (I had flashed it as a Flo to see if that corrected the external display scaling, spoiler, it didn't.)
Edit: Camera doesn't work for me even with a Flo kernel, something deeper is involved in that issue, but I am attempting to compile an issue list and workaround/observation list over in https://forums.ubports.com/topic/6056/nexus-7-lte-general-bugs-problems
I think what's needed is to go through the entire codebase, find quirks and hacks for the Flo and make them also run for the Deb, as 99% of the hardware is exactly the same (the Flo only misses the LTE modem and Sim Slot) and even run the same bootloader/baseband images.
Because I have recently picked up a 'deb' and after using the Nexus 7 WiFi (flo) I was expecting a very similar experience, seeing as they're effectively the exact same device with a cellular modem and a sim slot added (all the way down to the baseband and bootloader, the deb uses Flo images and is even just an add-on to the flo device tree when compiling Android).
Unfortunately, that was not meant to be, immediately after installing ubPorts, I noticed the following issues and set out to either workaround them or fix them. It's been a very long process and I am a newbie to compiling an Android system image (i've done many a kernel, and application, but never the full Android), so progress is slow. This post will serve as a chronicle of the issues found, and any applicable fixes.
UPDATE: This is indeed caused by the kernel image in use.
This issue is caused by two things, the kernel image that's shipped with the 'deb' installation, and a missing upstart unit in /etc/init for our device. This is easily fixed by compiling a kernel (or using a pre-built kernel) image for the 'flo' (Nexus 7 WiFi). Doing so actually appears to improve the stability and functionality of the device as a nice addition.
UPDATE: I have finally been able to get logs, I'll upload them when I get a chance!
When I say non-functional, I mean anything that even requests access to the Camera crashes. I created a Nextcloud webapp on my device and it would only open if I deselected the Camera permission. This issue is the most perplexing out of all of these, second only to the external pointer rotation issue, as there are absolutely NO logs generated regarding the camera, or any application that attempts to access it.
[NOTE]: I have invalidated this issue as it appears there are some slight minute differences between the Flo and Deb defconfigs that aren't represented in the current kernel trees, as building with the kernel configuration found in the ubPorts deb image's android rootfs yielded a kernel in which auto-rotation, slimport and reboot/power-down appear to function properly.
NOTE: Please note that you can use this kernel image in both a Flo and a Deb, however it may not boot on the Flo due to initramfs differences. If you install the kernel image on a Flo, I recommend extracting the kernel itself using abootimg and using the initramfs you already have.
Download Link: https://1drv.ms/u/s!AqACoL07fxpWp8gGGF_GTmO8f-tCKw?e=xe4VUt
Kernel Source Tree: https://tonoxisisle.services/git/TononixOS/ubports_kernel_google_msm
(don't mind the repository convention, I was working on making my own personal distribution using ubPorts as a base)
Please pardon my git mess, more android repositories will appear as I attempt to work through these device trees and the compilation process.
This kernel is a fork of ameyagokhale's lovely Anbox enabled kernel source tree and contains a couple extra additions:
Working zRAM module. In my own experience, zRAM has helped make the system more reliable as I have experienced less application crashing due to low memory than previously. It also removes some strain on our NAND chips by moving swap into a compressed space in RAM instead of a swapfile on the data partition. As our device does not use zRAM under Android, this driver remains uninitialized at startup. You can either create an upstart unit to set up zRAM which then triggers the zram-touch unit, or you can do the following in a terminal:
sudo zramctl -s <size> [Personally, I use 2G as the size]sudo start zram-touch which sets up ubPorts to use zRAM as it's swap, and dumps the SWAP.img image in /userdata, saving our NAND some write cycles.OverlayFS v13, this module is disabled and not compiled into my kernel images by default, if you want to play with this module, compile it yourself. I had originally pulled it in to provide rootfs overlay support for Anbox (allowing the installation of Google Apps and other System utilities), however Anbox crashed when creating the overlay. I find this extremely odd as I could create the same overlay by hand as root.
Obviously Anbox support! YES! We have Anbox support now (courtesy of ameyagokhale)! To use it, install the kernel image and then open terminal, then run the following commands:
anbox-tool installanbox-tool enableAnbox should start running and you should start seeing Android applications in the app drawer. Do note that applications do not rotate their orientation and thus must be used in their portrait orientation (as I understand it from reading issue tickets and the like, that is currently a limitation on the Mir port of Anbox that ubPorts is using). This is all very experimental.
Anbox support on the Flo/Deb is still very experimental, you may run into the following:
We have Anbox which uses LXC, does this mean we can use the LXC-type Libertine Containers?
No. For whatever reason, despite running Anbox's LXC container, and the Halium Android LXC container, Libertine runs into a namespace issue while creating it's container. Unfortunately, we are still very much a chroot-only device for the sake of Libertine.
I've downloaded your TonoKernel before for ubPorts 15.04, where are all the extra features like DoubleTap2Wake?
I opted to leave those out of this kernel tree, as I'm working to stabilize and improve the device support as much as possible, I'd prefer to keep extra features out of it while that work progresses. I have given thought to re-introducing those features in the future as a separate download, but I hope to eventually get this modified kernel adopted by ubPorts for the deb as it fixes a couple issues (mainly bluetooth).
I'm not so great with the actual Android development side of things, it would be an immense help to try to get a Halium 7.1 system image (that boots into ubPorts mind you) made for the Deb/Flo devices. My efforts keep ending up with a broken system that refuses to boot.
4/24/2021: Reformatted entire post to clean up the issue list and observations. As well as provide a clear structure for keeping this information on track.
4/27/2021: Removed kernel download link, it's getting replaced here in a couple hours.
4/24/2021: Attempting to build Halium-7.1 based system image for the Flo as research, my Deb image refused to boot the container. I'm curious if the Flo image will fare the same.
4/25/2021: Installed a easily compiled deb image, Halium got to starting the init process and then... nothing, no screen change, no logs, just nothing.
4/27/2021: I didn't even NEED to recompile Android, I just needed a good kernel configuration file for the deb. Turns out the flo_defconfig is missing some options, merging /system/boot/config-3.4.0-4-flo with my normal defconfig file has yielded a kernel with a vastly superior experience to the previous one in use (either by ubPorts installer or my own link here). I am recompiling the kernel using the new kernel configuration and it should be available soon after I test it.
4/27/2021: Kernel problem fixed! Bluetooth works, Auto-rotation works, Slimport works properly! Updated post with new download link and removed old invalid issues.
No one responded, so I figured I'd shine some light here. @walidham, Your port is built for armhf. You need to build for arm64 on the V20, we're not ARMv7, we're ARMv8.
So when building, you'd likely use ARCH=aarch64 instead of ARCH=armhf, if you made the device tree yourself, you may have other things that need done in the kernel's configuration.
@flohack Perhaps I misread the canonical write-up as to why snaps couldn't run then, but I was under the assumption that snaps couldn't work on the Flo because of some LXC features being unavailable. If that's incorrect, that's awesome and makes me wanna try to get Anbox up and running on the Flo!
I was also unable to create a LXC container when I attempted on my Flo last, claimed it was missing some sort of kernel support (I can't remember the exact message, but I'm going to be reinstalling UT here soon, so I can attempt again!) and was the same reason Libertine hardcoded itself to chroot if running on a vivid-based device iirc (unless I misunderstood that requirement, in which case, my apologies for the misinformation then!)
Also, I mis-spoke in my previous reply, Flo is on 3.4.0, not 3.5.0 ^_^; (EDIT: I also want to mention that I had forgotten to state that I was writing using what I had thought was the case from Vivid, I admit I haven't tried LXC on Xenial yet)
Btw, I'm literally ALWAYS happy to learn, so if I'm incorrect about ANYthing, please don't hesitate to correct me and let me know. I realize I'm human and can misunderstand what I read a lot.
EDIT: just finished attempting LXC inside UT, nope. fails initializing CGroup support, and libertine-container-manager claims "System kernel does not support lxc type containers. Please either use chroot or omit the -t option."
@wgarcia that JAR file (com.google.android.maps.jar) and any other accompanying JARs should be put in /system/framework. Not sure if the Anbox system image is writable though 
Treble is more about easing the process of updating the device and making it harder for an update to brick the device.
Treble requires the phone to maintain two system partitions, similar to ChromeOS. When an update comes in, it's applied to the unused system partition and then boot is switched it it.
Unfortunately, it doesn't solve the issue of drivers because, as stated above, it's simply a more safe and efficient update system. The drivers are still installed via the system update being applied to the unused partition as they were traditionally (they'd have to be, otherwise you'd have say 7.1 blobs on an 8.x systemand be unable to boot), and not coming from someplace else stored on the phone.
So sadly, other than making use of Treble's A/B partition update style, it doesn't help the issue of propreitary blobs.