If you still have one of these things around, why not running linux on it? Specifically, linux in a chroot environment. If you’re on the rooting scene, chances are that you’ve already heard of people doing this since well, the beginning of android. All the way back to the HTC G1. (e.g. this one and this) However, what all of these things have in common is the fact that in order to access X, VNC is going to be used. Now VNC is slow and buggy in my experience however some people have managed to hack their device’s framebuffer so that it can display the xserver. For example Thomas Polasek hacked his Nook color so that it runs lxde without that vnc bullcrap. Then quite recently someone modified an interim driver called xserver-xorg-input-mtev which makes it so that it works with more modern Xorg releases which can be found here. Installation is much easier thanks to Linux Deploy though you still need some command line know-how to configure our system. We are going to be using a Galaxy S II since well, that’s the one I have for this but other old devices should work fine. Apparently, newer devices are difficult.
The prerequisites are:
-A rooted S II
-Busybox. I recommend this one since it’s up-to-date. It’s made by the same guy who made Linux deploy.
-an external microsd card but for the sake of simplicity were going to install linux inside a large image file. But if you can, a microsd card.
-(Optional but highly recommended) Simple protocol player for pulseaudio
-An ssh client like putty
-Being able to write to the framebuffer
-An android terminal emulator or ADB
Now this tutorial is STRICTLY for the S II. Again this may work for older devices however the framebuffer may be different etc… so double check if your using other devices.
First off, let’s check if we can write to the framebuffer. Now why is this important? Because whatever we write on the framebuffer will directly be outputted on the screen. This way is 5x faster than vnc since it doesn’t have the overhead of the android ui and some networking of vnc. The downside is that the stuff that we write on the framebuffer is done by the CPU instead of the GPU due to the absence of drivers for the mali-400 so that also means that there is no hardware accelerated rendering. All is done by the CPU. Fortunately, our devices doesn’t have any constant refresh rate so if nothing is happening on the screen, the CPU doesn’t overwrite data 60x per second.
Step 1: framebuffer check.
Open either adb or a terminal emulator and type:
shell@android:/ $ su
If you see a superuser prompt on your screen hit grant then type:
root@android:/ # cat /dev/urandom > /dev/graphics/fb0
If you see something like this on your screen:
Congratulations, Framebuffer works! If not and you see errors then tough luck. Try /dev/graphics/fb1,2,3… But on the S II, it works just fine whatever rom your using. Don’t worry the garbled mess on the screen isn’t permanent. Just update the screen like going home or something and it should be gone.
Step 2: Setting up our linux installation
Open up Linux deploy and click the little arrow on the bottom left corner:
Which should bring you up to this screen:
Now for this, were going to use Debian jessie, armhf and the default img file. Any username and password will do.
Leave Priveleged users, DNS and Localization to default and enable INIT. Select run-parts as our init system. Leave init settings to defaults
Enable ssh (important!), Change Graphics subsystem from VNC to framebuffer
Change desktop to whatever you want, though I recommend MATE. Then go to framebuffer settings and change the settings to what you see on the right picture. Once everything is setup, click the menu button on your device or the 3 dotted button on an aosp rom and select install. After this, we will have the very long process of setting up the image, installing base system and other packages. This process may take you from 5mins. up to an hour depending on your internet connection.