Before installing, I went through a few extra flashes, just to make sure everything would go smoothly. I started out with putting back the original factory images, provided by Google. Download, unpack, and run the included script flash-all.sh. That was up and running within a minute or two.
That worked fine. Replicant booted, and it all looks good. Note that the recovery image which came with the Replicant build was an older version of the ClockworkMod, without touch. So, following the CM install steps above, I could have skipped that. But it doesn’t make a big difference.
The only problem with the Replicant image is that it does not contain a free version of the firmware drivers for things like WiFi and camera, and thus they don’t ship the proprietary binary blobs either. Now, that might be what you want, however, I choice to include the wifi binaries. I copied the ones from the CyanogenMod build. It went something like this:
First remount /system writeable adb shell
mount -o rw,remount -t ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name/system /system
Back on the terminal on the host computer, I extracted the firmware files, and copied them over. And then a reboot. unzip -x cm-10.1.2-maguro.zip system/vendor/firmware/*
adb push system/vendor/firmware /system/vendor/firmware
The last bit was to reinstall the various packages and configurations. For .apk files, they can easily be installed with adb. Then the configuration can be copied over. Just make sure the copied files get the same owner and group as its application. For some applications, like httpmon, this was easy. However, for K-9 it got a bit messy since the chown and chgrp commands are somewhat lacking. The later can operate recursively, but you still need to use both.
The Replicant distribution comes with the FOSS app market F-Droid pre-installed, so that’s convenient. That market includes applications like Firefox K-9 Mail, Gibberbot, APV PDF Viewer, httpmon, Orbot, Orweb. (It turned out that Firefox for ARM6 had to be downloaded from here).
CNET has an interesting article about how warrants to access suspects mobile phones are handled by two of the big mobile OS providers; Apple and Google. Focusing on Apple, the article mentions cases where the police has to wait for Apple to perform the unlocking, while Google “resets the password and further provides the reset password to law enforcement”.
From a technical perspective, it is not clear what kind of unlocking is performed; whether it is the SIM code, screen lock, or account password. It is interesting that the article mentions decryption, but it is probably a misunderstanding, or wrong wording: Android phones do not use encrypted storage by default, and in fact, if you have a model with a removable memory card, you can read that in any SD card reader. Accessing the embedded phone storage is also easy if it already unlocked (using fastboot / adb). iPhones does not use encrypted storage by default either, to be best of my knowledge. The article does indeed state that “It’s not clear whether that means Apple has created a backdoor for police [...] , or whether it simply is more skilled at using the same procedures available to the government.”.
From a privacy and security point of view, it is clear that it is irrelevant what the default security setting is. It can simply not be trusted to perform the task a user would expect. Rather, one should use take matters into own hands, and use software that has been proven to not contain backdoors for police or others. The only option is free and open source software, which has been vetted by security experts and the community.
In his insightful piece on Andy Rubin’s departure from the helm of the Google Android division, Charles Arthur looks into the future to see what’s next for the Android platform. He makes a case for a merge between Android and Chrome OS, however that has been speculated for four years already; even from the horse’s mouth.
What’s perhaps more interesting, is Arthur’s observation that Rubin was in fact a proponent of open source, and Android as a free platform, even though that was difficult to see at times. Arthur contrasts Rubin’s stance against Google’s and possibly Sundar Pichai’s (Rubin’s succeeder) desire to control the Android ecosystem. That path could conflict with handset manufacturer’s wish to brand and distinguish their products from their competitors. Arthur points out that about half of the 145m Android phones shipped in Q4 2012 were in fact not Google enabled (with a Google account, Gmail, etc). He speculates that the logical move for Pichai is to tighten control of the platform; making it less open.
That brings us to another headline: The general fight for control of devices, not just mobile phones, and the right to do whatever we want with the hardware we’ve bought, paid for and own. Kyle Wiens makes the case that we should be allowed to unlock any device, with tractors and cars as prime examples. These farmer and household items have become so complex to repair and maintain, that independent mechanics can no longer do the work. And even if they could, they are barred from access to embedded computers, sometimes based on proprietary tools and software, but also based on copyright, of all things. The access codes (passwords) are copyrighted, as are the service manuals, and only licensed technicians are granted access.
So are we headed towards the locked down nightmare Stallman warned us about sixteen years ago in his 1997 easy “The Right to Read”? If we keep letting mega-corporations have their way, that is a danger. However, as Wiens points out, Massachusetts passed Right to Repair legislation to make it possible to repair automobiles; other states are following. The White House petition to make it legal to unlock mobile phones did get a response, however, it is unclear if it is enough to avoid the criminal law which now applies to phone unlocking. Maybe there is still hope.
Last year I made the first progress towards a DIY remote for my home automation light switches (using the Everflourish RF based system). The goal was to use the 433.92 MHz radio transmitter and an Arduino to control the switches. Furthermore, the Arduino would receive control commands from my always-on computer, with Bash command line control (’cause that’s the way I like it). Finally, a custom Android app was developed as yet another option for remote control. The project is now fully operational, with a few adjustments here and there remaining. The figure below shows a high level overview.
From left to right, the mobile phones run Android apps which present a simple interface to control the lights. Each light can be turned on and off individually, or by some pre-sets (e.g. everything on or off, “good morning”, or “movie time”). The application has hard-wired the IP address of my always on server / PC on the local network. There is of course nothing stopping me from connection to a public IP (and port-forward), however, I don’t need away-from-home control at this point. The phone app simply sends a “light switch command” to the PC, which forwards it directly to the Arduino (see details below).
In this setup, the server is only a proxy, however, it could of course also be used to implement pre-programmed settings. E.g. daily rhythm commands when we’re away on holiday, or other automated functions. Since this box is also my PC, I can also send commands directly to the Arduino over serial /dev/tty; I have some convenience bash-scripts for that. For the phone app, it only does the forwarding on a hard-wired port:
while true; do nc -l 1234 > /dev/ttyUSB0; done
Maybe that bit could be improved in the future. Especially, since there are occasionally a few hiccups in the phone to PC communication. For example, the switch from 3G to local Wifi connection might be delayed as we enter the house, so commands will buffer up, and then suddenly sent en masse. Also, this would be a natural place to expand the system with pre-programmed actions. It should also be noted that to get this to work, I had to enable communication on the port 1234 both on the Wifi router, and the local server firewall.
Finally, the Arduino, connected via USB, accepts the incoming serial messages. The encoding is simple: A two digit code where the first digit is the index of the light, and the second is 0 or 1 for off or on (see the loop() method in the source listing below). So, “11″ will turn on the first light, while “10203040″ turns off all four lights. (Note that in the code below, to make things clearer for myself, index 0 is skipped).
The code below is all there is the the Arduino part. It hard-codes the Everflourish messages and timings. It should be noted that the messages as found in the previous article, are most likely some form of Manchester code, as there are always pairs of 01 or 10. Thus, the hard-coded messages could have been shortened, but this would have added (a bit) to the complexity of the code, so I left it.
The main loop waits for incoming bytes on the serial USB connection, and sends the according light switch command to the RF transmitter on pin 2. Here there is probably also room for some improvements, to avoid illegal numbers, stuck states, etc. Once a valid code is received, the transmitted signal for that button is repeated four times, just as seen with the original remote control.
“Freedom is not (just) a matter of principle. The reason that people take your freedom away from you is because they want, later at their option, to be able to take other things from you that would naturally be yours. Microsoft locks people into proprietary licenses because they know that, after a few years of using the OS they buy from them you will need a new computer and a new system, either because your old one broke or because an associate wants to do the same things as you do already. Normally, if you were allowed your natural right to copy things you own, you would just be able to copy the old one and that would work fine. By taking away that freedom, Microsoft is able to take away your money from you again later for nothing more than you could easily have done yourself if they didn’t interfere with your copying.
Google’s aim here is to make life difficult for competitors such as Amazon and the Chinese Android clone makers (not that these will care). This allows them to interfere with the free market for their own benefit. For programmers reading Slashdot, that means that, instead of being four or more potential developers of mobile software you can work for, Amazon, Google, Apple and the Chinese, there may well only be two: Apple and Google. With the possible exception of Jolla and Ubuntu, there is almost nobody else in the market who could consider competing. For people buying mobile phones would mean that, instead of having widespread choice from different vendors, everything would go through Google or Apple.
This is one of the key reasons why licenses such as the AGPLv3 as well as free software foundations which can provide a neutral holder for coyprights are so important. Look at how FreeBSD development has been absorbed by Apple even though it was supposedly “Open Source”. Without strong copyleft licenses the only choice will be which set of chains you wear. Once you are wearing those chains the only choice will be to give the mobile vendors what they want to take.”
I recently got my hands on an Asus Nexus 7 tablet. In it self, maybe not a groundbreaking device, if it wasn’t for the fact that Canonical will use it as their reference device for running Ubuntu on tablets and dual (or more) core mobile phones. Just to be clear, this is no dual boot, emulator, nor “chroot”-trick. The OS boots natively, and brings up the standard Ubuntu Unity desktop. The kernel is copied from (or based on) Google’s Android 4.1 kernel for the Nexus 7, which includes several non-committed changes, as well as binary drivers and firmware. See here fore more information.
Now, I said proof-of-concept, and what you get with this image is not really that handy on a tablet. So far, it just starts up a desktop Window Manager, which is not too comfortable with a touch screen. However, with a USB On-the-Go (OTG) adapter, you can plug in a USB hub, keyboard and mouse. Now it becomes usable like any other desktop. I got one of these compact ones from Deal Extreme, However, due to the rounded shape of the Asus Nexus 7, I had to chisel off a few millimetres to make it fit. The version with a wire would probably had worked better. Maybe also interesting to try would be a HDMI adapter (I’m not sure if that particular one works). Finally, the missing bit to have a fully functional docking setup would be charging while the OTG cable is connected. The Ubuntu FAQ mentions that this will be enabled, but you’ll probably need yet another special adapter cable to piece it all together.
What’s impressive about the current offering is that most, if not all, packages have already been compiled for the ARM architecture and are available in the Ubuntu repositories. This is very welcome, as it frees the tablet from the Android markets, and brings in an enormous selection of free and open source software. Not all of it is immediately suited for a small touch screen on a slow CPU, but that will change over time.
On a whim, I tried apt-get install emacs and eclipse. Both downloaded and worked fine, however, even with a four core CPU, ARM is not up to Eclipse quite yet. It should also be noted that the desktop UI has some unnecessary features which notably slows down the experience. For example, eye-candy like fading transitions when ALT-TABing between windows is enabled.
In conclusion, this is a very interesting first move from Canonical, and more GNU/Linux distributions will surely follow. With more alternatives and variety in this space, it will hopefully open people’s eyes up to the fact that the mobile phones and tablets they carry around are full-fledged computers in themselves, with no reason to remain restricted to a single OS from a single vendor. Maybe it will eventually turn stupid laws which makes it illegal to hack and experiment on these devices.
There has been quite a bit of news on the mobile OS space lately. We’re starting to see a trend of diversifying solutions, as opposed to the “me-too; Android” phones over the last couple of years. On the hardware side, Nokia is continuing its decline, but as this Guardian article shows, still delivers about a quarter of the handsets (smart and feature phones) to the Western European market. It is far surpassed by Samsung at almost 40%, while Apple, who only make smart phones, sold some 10% of the devices.
New on the block is Mozilla, with their Boot to Gecko, Mobile Firefox OS. They showed off screenshots this week. Mozilla has taken a bold step by basing all “native” applications and UI on HTML5. It should make applications easy to develop, however, there still has to be a OS specific API beyond HTML5 to handle features like cross-application intents (e.g. use this number to call), copy/paste, etc. and possibly hardware functions like camera, motion sensors, compass and so on.
To round off, a recent H-Online article by Andrew Back discusses how all the “open” alternatives still rely on proprietary hardware drivers for radio, and other auxiliary chips. As long as the fireware for these are closed there is a problem for security and freedom, he asserts. He mentions the OsmocomBB project as a free GSM implementation, but also that fully free and open software radios are unlikely to see the light, as it will not get certification by telecom regulators, and thus will be illegal to operate.
Andor’s Trail is a free and open (FOSS) single player RPG for Android. Although still under heavy development, the game is already fully playable, and the world map, quests and story is very impressive, with more to come.
Recently, an updated beta version was released, with even more maps and quests. The game is available from the FOSS market f-droid.org, and Google’s Play Market.
However, as pointed out in the Slashdot comment above, this project will always trail Google’s releases. And as we’ve seen previously, the source codes does not always follow the release of the OS. Furthermore, Android in itself is not the most exciting OS around. The MeeGo (and presumably Tizen) initiatives are more standard GNU/Linux distributions from the get-go. Including features we’ve taken for granted over the last ten years or more: dependency resolving, updates over repositories, GNU applications. Of course, these will struggle with exactly the same problem: the proprietary drivers.
As mentioned on the Wiki, and seen in the source, the page size can be 2048 or 4096 bytes, with the former the default. The header, which is rather boring, containing only a “magic string” (“ANDROID!”) and a checksum takes up the first page of 2048 bytes. It can be separated from a boot.img with the following command:
dd bs=2048 if=boot.img of=header count=1
Next up is the kernel. I’ve yet to find a way to determine its size, however you could go looking for white space padding and then round up to the nearest 2048 bytes. (Also, magic bytes (1F 8B) of the gzipped ramdisk will provide a clue.) In my case, I “cheated” and looked at the size of the kernel file under out/target/product/maguro. It turned out to take 1912 pages, so we can separate it by the following command (skipping the header part):
As seen from the files above, the charger icons displayed when the phone is charging while off is plain PNG images. Might be fun to change. Furthermore, the initial splash screen logo can be changed by adding a file called initlogo.rle to the root directory of the ramdisk. Might try that next.
Here’s a brief command-by-command guide to building Android 4 (ICS -Ice Cream Sandwich (with extra sugar on top)) from scratch, and deploying the new images on the Samsung Galaxy Nexus, all from Fedora 16. This is heavily based on the Free your Android article, and of course the instructions at android.com.
First, install the supporting packages. (Instead of the OpenJDK version, you might have to download the Oracle one, if you get version conflict errors at the make step below.)
Assuming the Galaxy Nexus – GSM/HSPA+ (“maguro”), there’s two drivers. (Please check the link above for new versions).
tar zvxf imgtec-maguro-iml74k-a796ffae.tgz
tar zvxf samsung-maguro-iml74k-de1cc439.tgz
Build, still assuming the same phone as above. On my somewhat dated dual core 2.6 GHz CPU, it took almost four hours to compile.
Then, transfer the image files to the phone. Make sure the phone is connected over USB, is unlocked, and has USB debugging enabled. After the images are transferred, and the userdata and cache partitions are erased, the phone will reboot. It will show the Android logo, reboot one ore two times more, and then wait maybe a minute or two before the UI is available. And there it is, your home-built Android OS.
In the world of OSes for mobile phones, there have been a lot of changes lately, with some going away and others joining the race. A while back, Intel announced that they would drop MeeGo, which means that it is dead since there is nobody else to support it if the community can’t keep it going. But at the same time, they said the code would be merged with another mobile OS. Intel and the Linux Foundation will be steering the OS with the very unfortunate name Tizen (it can easily be mistaken for meaning penis in some of the Scandinavian languages).
The story does not end there, though. Amongst the free mobile OSes, KDE is entering the race. Not with a complete separate OS, but rather a UX platform, Plasma Active, with an API for phones, tables, set-top boxes, home automation, and so on. Plasma Active has to run on top of some OS, and currently they are using MeeGo and openSUSE based Balsam Professional.
It is refreshing to see a lot of movement in this area, and hopefully it will lead to a free alternative. However, the at moment it is still looking somewhat bleak for truly free mobile phone OSes. The firmware and driver issue seems to be never ending, and not even the OpenMoko can escape it.