Posts tagged ·

Android

·...

Android SDK tools on Debian Wheezy

no comments

After downloading the Android SDK bundle, I could not start adb and fastboot, getting somewhat bizarre error messages like:

bash: ./adb: No such file or directory

bash: ./fastboot: No such file or directory

./adb: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

All of those were due to missing dependencies for i386 libraries. Doda’s article on the topic solved the issue. They can be installed by:

dpkg --add-architecture i386
aptitude update
aptitude install libstdc++6:i386 libgcc1:i386 zlib1g:i386 libncurses5:i386

Replicant on Galaxy Nexus

Comments Off

After nearly two years on a custom built Android OS, it was time to upgrade. I now have the latest (4.0.4) Replication build for Galaxy Nexus running.

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.

Next, I tried CyanogenMod’s build for Galaxy Nexus, including the ClockworkMod Recovery boot image. I used the touch image found here, and simply flashed with:
fastboot flash recovery recovery-clockwork-touch-6.0.3.6-maguro.img

I used the cm-10.1.2-maguro.zip from here, and followed the installation procedure using the recovery image seen here. The only difference was that I had to boot the phone fully to have access through adb. Pushing the zip file while in recovery mode did not seem to work. Besides that, everything went smooth. It’s probably worth noting that the camera still works with the CM 10.1.2 build.

So far, so good. Now for the Replicant images. I downloaded the 4.0 0004 build. The instructions suggests the Heimdall recovery image for installation, but I tried to flash through fastboot instead. Thus the install went something like this, while the phone was on the bootloader screen (not in recovery mode).

sudo fastboot erase boot
sudo fastboot erase userdata
sudo fastboot flash boot boot.img
sudo fastboot flash recovery recovery.img
sudo fastboot flash system system.img
sudo fastboot flash userdata userdata.img
sudo fastboot reboot

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
su
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.

adb install Gibberbot-37.apk
adb install httpmon-27.apk
 
adb push org.jtb.httpmon /data/data/org.jtb.httpmon

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).

Comments Off

Police “decrypts” your phone

Comments Off

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.

Comments Off

Mobile lockdown?

Comments Off

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.

Comments Off

Home automation with Arduino and Android

Comments Off

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.

(Download source)

#define OUT_PIN 2

// Timings in micro seconds
#define SHORT_UP_0 567
#define LONG_UP_1 1134
#define DOWN_SPACE 680
#define UP_END 15000

const int PREAMBLE = {0x00};
const int OFF[] = {0x55};
const int ON[]  = {0xaa};

const int light_array[][5] = {
  {},
  // main
  {0x65, 0xa9, 0x46, 0x95, 0x67, },
  {0x65, 0xa9, 0x46, 0x96, 0x96, },
  {0x65, 0xa9, 0x46, 0x99, 0xa3, },
  {0x65, 0xa9, 0x46, 0x9a, 0x61, },

  // aux
  {0x65, 0xa9, 0x46, 0x95, 0xaa, },
  {0x65, 0xa9, 0x46, 0x96, 0x53, },
  {0x65, 0xa9, 0x46, 0x99, 0x62, },
  {0x65, 0xa9, 0x46, 0x9a, 0xa1, },
}; 

void setup() {
    Serial.begin(9600);
    Serial.println("setup");

    pinMode(OUT_PIN, OUTPUT);
}

void loop() {
  if (Serial.available() > 1) {
     int light_id = Serial.read() - '0';
     int on = Serial.read() - '0';
     Serial.print(light_id);
     Serial.println(on);
    
     for(int i = 0; i < 5; i++) {     
       send(light_array[light_id], on);
     }
     
     //delay(500);
  }
}
  
void send(const int *light_data, boolean on) {

  digitalWrite(OUT_PIN, LOW);
  delayMicroseconds(LONG_UP_1);
  
  send_bytes(PREAMBLE, 1, 4);
  send_bytes(light_data, 5, 8);
  send_bytes(on ? ON : OFF, 1, 8);

  digitalWrite(OUT_PIN, HIGH);
  delayMicroseconds(DOWN_SPACE);
  
  digitalWrite(OUT_PIN, LOW);
  delayMicroseconds(UP_END);

  digitalWrite(OUT_PIN, HIGH);
}

void send_bytes(const int *bytes, int len_bytes, int len_bits) {
  for(int b = 0; b < len_bytes; b++) {
    int data_byte = bytes[b];
    for(int i = len_bits - 1; i >= 0; i--) {
      digitalWrite(OUT_PIN, HIGH);
      delayMicroseconds(DOWN_SPACE);
    
      digitalWrite(OUT_PIN, LOW);
      int data_bit = ((data_byte >> i) & 1);
      if (data_bit == 0) {
        delayMicroseconds(SHORT_UP_0);
      } else {
        delayMicroseconds(LONG_UP_1);
      }
    }
  }
}

Comments Off

Freedom is not a matter of principle

Comments Off

In today’s news, the terms of the Android SDK has changed. However, it seems it was not open source in the first place. What’s always interesting though, is the discussion it spurs, with insightful comments on Slashdot.

Comment by “rtfa-troll”:

“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.”

Comments Off

Ubuntu on the Nexus7

1 comment

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.

A decent proof-of-concept build of Ubuntu 13.04 is already available, and it runs fine on the Nexus 7. If you’re running Ubuntu on your desktop, a pre-packaged installer is available from the a repository. Alternatively, download the boot and userdata images, and install using fastboot yourself. (All commands below need sudo).

fastboot devices
fastboot erase boot
fastboot erase userdata
fastboot flash boot raring-preinstalled-desktop-armhf+nexus7.bootimg
fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img
fastboot reboot

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.

Mobile OSes

Comments Off

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.

On the software side, Google released Android 4.1, including source code, while Facebook has announced their own customized OS, however it is likely to be Android based. Meanwhile, old Nokia employees still believe in their adopted child, MeeGo, and has forked off a company to continue development.

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.

Comments Off

Andor’s Trail

Comments Off

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.

Comments Off

More Android Apps

Comments Off

Following the list from yesterday, here’s more useful Android apps, this time both from the F-Droid and Android Market (aka. Play). First from F-Droid (APK file):

And from the Android / Google Play Market

Finally, there’s a few which can, or have to, be downloaded from the creator’s web site:

Comments Off

Cell phone privacy guide for Android

1 comment

The Pirate Party of Canada has a nice list of applications and add-ons for Android phones which enhance security and privacy. It boils down to

Replicant – Free Android alternative

Comments Off

The Replicant project was covered by Computer World today, with an interview of one of the main developers Paul Kocialkowski. The article was also picked up by Slashdot, where the mod was more cynical. Kocialkowski talked about the importance of free hardware and software when communicating in an insecure environment, and the difficulty of implementing an alternative when many of the drivers and firmware for key hardware is proprietary and secret.

Currently, Replicant is only supported by a few phones, including HTC Dream, Nexus One and Nexus S. The last one is probably interesting, as it is still a reasonably modern phone, can run Android 4.0, and have “factory binaries” available so you can start from scratch if you get stuck.

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.

Comments Off

Android: Unpacking boot.img

Comments Off

After successfully building the Android OS, and flashing to the Galaxy Nexus, I’ve started investigating how it all hangs together. Starting with the boot.img, and unpacking the parts; header, kernel, and ramdisk. The structure is explained in detail on the Wiki android-dls.com, but also in the source for building the boot.img file.

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):

dd bs=2048 if=boot.img of=kernel skip=1 count=1912

Then it’s only the ramdisk filesystem left (there’s no “second stage” section in use). It will take the rest of the size of the file, which came down to 158 pages in my case:

dd bs=2048 if=boot.img of=ramdisk skip=1913 count=158

The ramdisk is a gziped, cpio packed archive, which can be extracted into its own directory by
mkdir ram
cd ram
gunzip -c ../ramdisk | cpio -i

That should give you the following files and directories

./init.rc
./ueventd.tuna.rc
./init.omap4pandaboard.rc
./res
./res/images
./res/images/charger
./res/images/charger/battery_4.png
./res/images/charger/battery_5.png
./res/images/charger/battery_1.png
./res/images/charger/battery_charge.png
./res/images/charger/battery_2.png
./res/images/charger/battery_fail.png
./res/images/charger/battery_0.png
./res/images/charger/battery_3.png
./init.tuna.usb.rc
./ueventd.goldfish.rc
./dev
./init.tuna.rc
./init.goldfish.rc
./init
./system
./data
./sys
./ueventd.rc
./sbin
./sbin/adbd
./sbin/ueventd
./proc
./charger
./default.prop

For more about the Android boot process, and kernel, look at the Embedded Linux Wiki.

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.

Comments Off

Building Android on Fedora

2 comments

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.)

yum groupinstall "Development Tools"
yum install java-1.6.0-openjdk kernel-devel git gnupg flex bison gperf zip curl zlib-devel glibc-devel glibc-devel.i686 ncurses-devel.i686 glib-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686 libX11-devel.i686 libXrender.i686 libXrandr.i686 mesa-libGL-devel.i686 readline-devel.i686 arm-gp2x-linux-gcc-c++ python-markdown xmlto libxslt

Download the source. The final sync command will take about an hour.

curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
chmod a+x ~/bin/repo

mkdir android
cd android

repo init -u https://android.googlesource.com/platform/manifest
repo sync

Download proprietary binaries and drivers. They are available here:

http://code.google.com/android/nexus/drivers.html

Assuming the Galaxy Nexus – GSM/HSPA+ (“maguro”), there’s two drivers. (Please check the link above for new versions).

wget https://dl.google.com/dl/android/aosp/imgtec-maguro-iml74k-a796ffae.tgz
wget https://dl.google.com/dl/android/aosp/samsung-maguro-iml74k-de1cc439.tgz
tar zvxf imgtec-maguro-iml74k-a796ffae.tgz
tar zvxf samsung-maguro-iml74k-de1cc439.tgz
extract-imgtec-maguro.sh
extract-samsung-maguro.sh

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.

source build/envsetup.sh
lunch full_maguro-eng
make -j4

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.

out/host/linux-x86/bin/adb reboot bootloader
sudo out/host/linux-x86/bin/fastboot -w -p maguro flashall

If something, or everything, failed and you are left with a useless phone, here are the factory images from Google. Download and unpack the archive corresponding to your phone, and run the script

flash-all.sh

For more details on “unbricking” your phone, see Derek Ross’ comment.

Mobile OS

Comments Off

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).

Meanwhile, over at Nokia they are betting on Windows Mobile (and making many of their employees disgruntled), while at the same time releasing the already defunct MeeGo OS in their N9 phone. However, since these are all OSes for high end smart phones, they also need something for their so called “feature phones” which are not power full enough (or have different user groups) to drive all the complex functionality. Enter Meltemi, ironically enough a Linux based OS to replace Symbian S40 series.

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.

Comments Off