jump to navigation

Android Lessions Part 1: Bluetooth Crash January 4, 2012

Posted by Florian in Android, Source.
add a comment

Finally – some free days for family and friends and to write a few lines which might be useful for someone else. Since Android started to become more and more interesting for industrial and business applications I got involved in some projects porting Android to several devices. It turned out that the documentation of the lower layers (hardware and driver adaptation) is very thin in contrast to the SDK and NDK documentation. But I took some notes working on these projects… this one might be useful for other people porting Android 2.3.x and experiencing issues with Bluetooth.

I ran into the issue that activating Bluetooth in the settings application resulted in a crash of the whole GUI. It seems that only ARMv5 core based devices are affected so that only a few people ran into this so far. (Not that it would be correct on more common cores used for Android devices such as ARMv7A, but it does not seem to cause the same effect.) The solution I found in the Android 4 commit log is quite simple for a problem causing that much of hassle:

--- a/core/jni/android_server_BluetoothEventLoop.cpp
+++ b/core/jni/android_server_BluetoothEventLoop.cpp
@@ -311,7 +311,7 @@ static int register_agent(native_data_t *nat,
DBusMessage *msg, *reply;
DBusError err;
- bool oob = TRUE;
+ dbus_bool_t oob = TRUE;

WebOS goes Open Source December 9, 2011

Posted by Florian in Linux, Source.

Amazing news! HP just announced that WebOS will become an Open Source project lead and supported by HP in future. The full annoncement can be found here.
HP has an official press release about this here. I’m really looking forward to work with it… It’s quite an interesting framework for a large number of devices. The really funny thing is that Nils asked them to do so in his blog some weeks ago :-)

MeeGo – some feedback and thoughts February 15, 2010

Posted by Florian in Devices, Linux, Maemo, MeeGo, OpenEmbedded, Source.

I only had a very few free minutes today I was able to spend following the discussions and reading released information about MeeGo. For some reason the most intensively discussed fact among the community members  seems to be decision to use the RPM package system. This one is followed by the Qt vs. GTK+ discussion I cannot remember when it started but I still remember it even started before I wrote the first line of open source code :-)  I have seen a lot of questions about currently existing devices (N900 mostly) and software –  if they are likely to become supported in future MeeGo releases – at least for the N900 and Maemo 6 there is a statement by Ari Jaaksi already. The other technical questions… well, in an ideal world these should not even be relevant for the developers because there would be the perfect tools that create the packages you want and assist you to create user interfaces without thinking much about the toolkits you  use. Again – this is the theory – we all know that the real life for development is quite different. But in the end or customers / users will decide which platform and with this which applications they are going to use. Users will not care about the package format used in the platform or the toolkit that is used by some application. In fact many (mostly Linux/Unix based) platforms do not expose the software package file format to an average user any more while some quite popular ones still do (e.g. Symbian and Windows). For users the availability of a consistent and widely used software platform with a high amount of available applications is likely to be the most important criterion. Ok, I admit that the availability of sexy hardware is quite important too :-)

Way more interesting than technical details is to look at the landscape of mobile device software stacks and to place MeeGo in it. So how does this landscape look like now?

  • There is Apple with the iPhone – pretty much closed but many developers and sexy hardware but quite limited amount of devices and only one manufacturer.
  • Symbian – well established with a large community but it feels like it hits its limits with modern smartphones.
  • Samsung just launched Bada which looks quite interesting but does not yet seem to have a large community of developers and users.
  • Microsoft Windows Mobile is available for many years now but seems to have lost attraction over the years.
  • Palm WebOS is interesting from both developer and user point of view but I think it will be hard for it to compete with all the major players in this area.
  • Google developed Android which enjoys a fast growing user- and developer base. It’s easy to get started with Android and there is a wide range of interesting devices available already. It is quite portable since most of the lowlevel components are open source.

Among these the most likely candidate to play the dominating role in the mobile handset market might be Android. At least this is how things look like right now… we all know this market changes pretty fast and you never know what happens next. I think Nils asked the question quite a few of us asked themselves: Will MeeGo become a kind of “Android killer”?

No way I will comment on this but in order to become a more generic platform MeeGo needs to focus on different things Maemo did so far. So far Maemo was focused on supporting a very few devices and contained quite some specialized bits that only worked for the Maemo specific devices and its distribution. I still remember that getting basic support for building the Maemo software stack with OpenEmbedded caused some headaches and sleepless nights. (I was mentor of a GSoC project working on this – just take a look at Kirtika’s blog to find out some details.)  It is good to see that it is quite obvious that MeeGo folks understand that these things will have to change. A good example is the process how to get some hardware supported. For someone like me supporting various device makers the really interesting part will follow: How will the device makers adopt MeeGo and how many of them will ‘jump onto the MeeGo boat’? Having more hardware vendors supporting MeeGo means more users and meant to make the platform more interesting for developers. And gaining interest from developers and users is absolutely vital for any software platform that is going to play a major role in future.

In my opinion there is a lot of potential in MeeGo – the most important one is the fact that the key components are going to be open and portable. The project joins two (comparably small) developer and user communities and combines this new community with the support by two very successful companies. I can imagine that this base is able to attract quite some more valuable contributors like smaller device makers, software companies and open source projects.

I’m pretty sure that ‘The Big Merge’ is going to cause quite some movement in the mobile device landscape…

FOSDEM 2010 February 9, 2010

Posted by Florian in Devices, Linux, OpenEmbedded, Source, World.
add a comment

Something was wrong with FOSDEM this year: The weather – it was (comparably) warm and the sun was shining all the time!  Apart from this it was a great event like always. I attended it representing the OpenEmbedded project with a small booth. From the OE project perspective FOSDEM was a great success. Apart from meeting people working on other projects that do use or could use OE we had a lot of interest from various other visitors at the booth.

Visitors at the OE booth

Visitors at the OE booth

Some things I noticed during my time at the booth is that we have to improve the presentation of the project a little bit. For many visitors even on a developer event like FOSDEM OpenEmbedded is a quite uncommon project and hard to present. We showed a set of different devices at FOSDEM but we always need to explain that these devices are just samples for possible OE target devices. It’s not really obvious how to communicate this… One improvement could be to add sheets with OE information to the devices we show. We should list things like this:

  • Name
  • CPU Architecture
  • Useful OE targets

Another thing I miss is a kind of poster or info sheet that summarizes OE achievements in some lists and numbers. But anyway I think we are getting better and become more and more popular.

Device collection

Device collection

We have to thank all the project members who helped with our booth – most notably Alessandro, Robert, Marcin and Henning for spending a lot of time at the booth. Special thanks should go to Ulf (from Atmel) and Vladimir (from Archos) who made it possible to have some more interesting devices to show. I think this is the first time we didn’t have a single Zaurus at the booth… :-)

One more project / booth I think is worth to mention is Rep Rap / Makerbot. The bots for turning 3D models into real things you can touch and use gained quite some attraction.

Bots at the booth

Bots at the booth

Bot detail

Bot detail

Did you notice? You can even use these bots make parts for another one… I think it is worth following these projects. They might become quite important to us in near future.

A working Makerbot - just finished a job

I would have some more things to write about – there were a lot of interesting things going on at FOSDEM but like always time is lacking. More as soon as I manage to write some more lines…

Anjuta Plugin for OpenEmbedded SDK June 18, 2009

Posted by Florian in Devices, kernel concepts, Linux, OpenEmbedded, Source.
Tags: , , , , ,

I have always liked the idea to have an Anjuta plugin that simplifies the use of cross toolchains in order to develop for all sorts of mobile and embedded devices. Personally I do not rely on an IDE but I have worked with a lot of developers in the past who are not used to do application development with vi. The same applies to cross toolchains, but there are reasons why people compile natively or why tools like Scratchbox are developed.

Some time ago OpenedHand published an Anjuta plugin for Poky that almost fits these needs – apart from minor lacks and the fact that you can’t use it with an OpenEmbedded build tree because it relies on the Poky directory layout. It didn’t take me long to modify the Poky plugin to fit the needs for OpenEmbedded: I have added automatic detection of the toolchain host prefix and some functionality to deal with the (not 100% fixed) directory layout of OpenEmbedded. So what does it do?

  • Select a toolchain or OpenEmbedded build directory to use
  • Configure and build a project
  • Deploying of binaries to a target device using rsync and ssh
  • Some debug and remote device features from the original plugin I didn’t test so far
Anjuta OpenEmbedded SDK Plugin

Anjuta OpenEmbedded SDK Plugin

It is easy to install (and build if necessary). I have created an initial website for it at KC Labs. You can find both source archive and binary packages for Ubuntu (9.04) and Debian Lenny. Once you have it installed it you should be able to design your GUI, fill it with functionality and deploy the application to a target device withouth leaving Anjuta.

Feedback is very welcome – if you have ideas about new features or what you would like to see for cross development please let me know!

Have a nice time…

PS: LinuxTag is approaching – visit the Embeded Area with projects like OpenEmbedded and Coreboot!

MOTODEV Studio for Linux: A brief review August 27, 2008

Posted by Florian in Devices, Linux, Source.

Knowing several SDKs for mobile devices available in the market such as OpenMoko Freerunner, Nokia N810 and several other I decided to take a look at the new MOTODEV Studio for Linux by Motorola. They published the preview release 0.3 a short time ago. Its quite appealing to write applications for all the MOTOMAGX devies out there. But it turned out that it is not really easy and the fun seems to be limited even if the MOTODEV Studio itself looks and feels quite nice.

The MOTODEV Studio preview comes as a 381MB zip archive which contains install instructions (PDF) and an executable binary installer. Even if the website says that it requires RHEL4 it installed without trouble on my Ubunty 8.04 after switching from GCJ to a SUN JRE. It requires ~900MB of disk space (no 3GB like the website says). There is an installer for Windows as well, but trying this is a job for someone else ;-)

The Eclipse (they use 4.0.3) IDE’s developer perspective looks pretty good and is easy to use even for developers who are not used to Eclipse at all. Only the fact that it needs a big screen to become useful is a problem for the users of many laptop computers which do not offer a screen higher than ~800 pixels. Resolutions below 1280×1024 result in a very small editor window.

Developer Perspective

Note the documetation browser at the right side of the window. There is a lot of documentation included already and integrated into the Eclipse help mechanism.

The VMware set-up and creating a configuration for the device emulator is rather trivial with the step-by-step instructions. Make sure to have VMware player 2.0.4 installed – the website still has 2.0.3 as a requirement which did not work for me.

The device emulator starts a VMware instance booting into a Linux system. Once the emulator is running it opens a tab in the IDE with a virtual device. It somewhat reminds me to Xoo :-)

IDE with emulator

IDE with emulator

With a set of example applications included it is very easy to get an application started. Creating a new project you are offered five application skeletons to choose from which includes a GUI application that shows how to use the contact database API.

So far the whole SDK looks really promising and much more convenient for Linux developers than the Series60 SDKs. But currently there are some bad limitations:

  • No integration of real devices yet – no binaries for a real handset and no debugging on a device.
  • They say that current MOTOMAGX devices won’t be supported by the native SDK and support will be limited to the next generation of devices.
  • Even if Motorola call MOTOMAGX an ‘open’ platform its openness is very limited and does not really compare with an open platform open source developers would like to see. Environmets like OpenMoko or Maemo offer a way higher degree of freedom.
  • The developer community and therefore the number of applications available is quite likely to be small in near future – compared to established platforms at least.
  • Some strange limitations in the IDE like the fact that source files are only usable if they have the extension ‘.cpp’ might make it quite hard to port existing software.

All in all its a big step into the right direction, but there is atill a hell of a lot of work to do. I guess it would be a nice idea for some MOTODEV Studio developers to have a chat with us Maemo people at OSiM next month.

Have a nice time…

Maemo Summit July 22, 2008

Posted by Florian in GPE, kernel concepts, Linux, Maemo, Source.
1 comment so far

Good news for me… after missing GUADEC and other interesting events it looks like I’ll make it to the first Maemo Summit in Berlin. The list of participants is quite impressive – I guess this will be a really interesting event. Just join us there :-)

I read a few lines about odeviced… anyone else who thinks that using something like this for Maemo might be a goo idea?

I do not have much time left for blogging and coding currently – family and work keep me busy these times. But a few good things are in prgress – OpenSync’s roadmap indicates that they are close to a new release. This will be a much better base for MaemoSync than current SVN trunk. Even GPE makes a little bit of progress. Graham continues fixing various PIM bugs and gpe-memo is close to become ready for its first release.

Have a nice time…

LinuxTag is (almost) there May 27, 2008

Posted by Florian in Linux, Maemo, OpenEmbedded, Source.
add a comment

In a few hours LinuxTag 2008 will open its gates. There is a large booth for mobile and embedded Open Source projects in hall 7b – I’ll be there for OpenEmbedded. GPE is there and right next to us there is the booth of the OpenMoko folks.

Using CMake for Maemo development April 11, 2008

Posted by Florian in Linux, Maemo, Source.
add a comment

Since OpenSync switched to CMake build system I had to get along with CMake in the Maemo SDK. I have to admit the fun was limited. In fact CMake has some advantages over autotools – most notably: It is much faster. One major drawback is that it is more complicated to use pkg-config with it.

I have never worked with CMake before, but OpenSync had some quite good examples how to check and support additional libraries. So I hacked cmake support for some basic Maemo components (libhildon, libosso) and Maemo-like Debian packages.

My cmake files can be found here:


CMake itself is in the official extras-devel repository at maemo.org. Just add this line to your sources.list:

deb http://repository.maemo.org/extras-devel chinook free

The package is available for all other SDKs from the same location.

The DpkgDeb.cmake file is based on the updated DpkgDeb.cmake by Mehdi Rabah. The other ones are based on random files found in OpenSync SVN.

Maemo Sync packages April 2, 2008

Posted by Florian in GPE, Maemo, Source.

I have made an installable package for Maemo Sync, but do not expect too much. Its a basic port of the current Multisync-gui to Maemo. It is only tested to so far that the GUI starts up and registeres correctly. The fact that I had to use cmake for building Maemo software caused some headaches here… the quality of the source distribution package is still quite bad.

I also did not decide if I want it to become a project forked from Multisync-gui or to maintained with Multisync-gui adding optional support for Maemo environment. The always changing OpenSync API would be a reason to stay with Multisync-gui, but the fact that I have different opinions about UI design, Glade is involved and cmake are reasons for making it a separate project.

Binary package and sources are located here. You also need the OpenSync packages from Graham’s daily repository.

Another minor improvement of the GPE application packages in this repository is that latest Starling supports OGG playback. You only need to have an OGG plugin for GStreamer installed. The mogg package provides this for example.

Any feedback is welcome – if you manage to sync data with either the command line tool msynctool or using Maemo Sync please drop me a line. I would like to collect information which sync peers work with latest OpenSync and how to set up these.