Not all android UI designers are coders. The eclipse layout editor is atrocious and doesn’t show you what you’ll get at run time. The emulator is too slow. And sometimes you’re trying to design a screen for a process that doesn’t exist yet.

So what can we do to reduce the turn around time for testing what an android layout actually looks like on a specific device?

First I was thinking that it should be possible to build a minimal resource bundle and open it from a generic, pre-installed application. Nope, not going to work. While the SDK allows you to examine some details about an apk without installing it, I couldn’t find a way to explode a layout. If you have to install it anyway, you might as well build a custom application every time.

So how can we get a list of the layouts in this application? What about reflection? Add a small class that gives you a list based on R.layout.class.getDeclaredFields(). Then pass the resource value to another simple activity that can show the result? Hmmmm, that could work. But these activities would need to be built into your application. Or build the resources into another smaller test application…. That’s a much better idea.

It works, and it’s really quite simple;
https://github.com/lakeman/layout-preview

Simply clone the above repository, symlink or copy the res folder from another application. Build, install and open. Ta-Da, rapid layout previews on actual android hardware.

Related articles

• Wireframing and UI Development (servalproject.org)
• Android UI Fundamentals (Peachpit Press) (i-programmer.info)

By: Torkild Retvedt

The core of the Serval Maps application is powered by the mapsforge library which uses OpenStreetMap data to render maps. The OpenStreetMap data myst first be converted in a binary format specific to the library and stored in the external storage of the Android device.

Last week I started exploring how we can make the conversion of the OpenStreetMap data into the binary format used by mapsforge easier. The place I chose to start is the use of PostgreSQL to store OpenStreetMap data.

With thanks to ITShare SA I was able to put together an Ubuntu based server using a Pentium 4 CPU with lots of hard disk space and RAM to explore this type of activity.

The most complete source of data from OpenStreetMap is known as the Planet file, and the main application used to work with this file is known as Osmosis.

Given that the binary version of the Planet file is over 16GB of space I expected the process to take some time. What I didn’t expect was that it would take 3 days to complete the import of a planet file into a PostgreSQL database. That is a very long time!

techxplorer@trellheim:~$ /data/openstreetmap/osmosis/latest/bin/osmosis --read-pbf file="/data/openstreetmap/planet/planet-120401.osm.pbf" --write-pgsql user="osm" database="osm" password="osm"
18/04/2012 10:50:42 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.40.1
18/04/2012 10:50:42 AM org.java.plugin.registry.xml.ManifestParser <init>
INFO: got SAX parser factory - org.apache.xerces.jaxp.SAXParserFactoryImpl@1c78e57
18/04/2012 10:50:42 AM org.java.plugin.registry.xml.PluginRegistryImpl configure
INFO: configured, stopOnError=false, isValidating=true
18/04/2012 10:50:42 AM org.java.plugin.registry.xml.PluginRegistryImpl register
INFO: plug-in and fragment descriptors registered - 1
18/04/2012 10:50:42 AM org.java.plugin.standard.StandardPluginManager activatePlugin
INFO: plug-in started - org.openstreetmap.osmosis.core.plugin.Core@0.40.1
18/04/2012 10:50:42 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
18/04/2012 10:50:42 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
18/04/2012 10:50:42 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
21/04/2012 10:16:06 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline complete.
21/04/2012 10:16:06 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Total execution time: 257124838 milliseconds.
techxplorer@trellheim:~$

Some of the things I’ve learnt along the way:

1. Having never administered a PostgreSQL database before I found it rather different, for example changing to the specific postgre user to administer the server and run SQL commands;
2. The osmosis application uses a lot of  temporary space when undertaking an operation like this, ~300GB
3. The completed PostgreSQL database is ~417GB when the process finished

My next task now is to see if all of this work is worth it, and that it is faster to process an extract of data into the mapsforge format from the database as opposed to the flat file.

Logic suggests it should be, which is why I undertook the work, but I need to undertake the experiment.

Some resources that I found useful:

• PostgreSQL database page on the OpenStreetMap wiki
• Osmosis/PostGIS page on the OpenStreetMap wiki

The “Server room at CERN” was uploaded to Flickr by Torkild Retvedt and used under the terms of a Creative Commons license.

1) doing PhD over next few years
2) frantically coding for May release for the Serval Project
3) now working for the next two years at Flinders University as an academic – a lecturer in two Comp Sci/Eng topics
4) after two years, if all going well with PhD, get employed by uni as perm staff
5) continue with the growing excitement of Serval
6) one last trip to IEEE as handover- but continuing research on IEEE network issues
7) we have a sleepover party* for ms 10 tonight, so caused epic spring clean, very little of which i can do with disability

*5 ten years olds – meep!

One of the very early design decisions was to use public keys are the mechanism for identifying phone users at the network level (at the human levels, it is all phone numbers, so that it remains easy to use).

By using public keys as the network identifier, we get some very nice properties.  By carefully choosing the cryptographic algorithm we are gain the ability to perform a Diffie-Hellman shared secret agreement process.  This makes it possible for any two parties to encrypt their mutual communications, without them having to first establish contact. This provides the same major security benefits (confidentiality, authenticity of communications) of insanely complex systems such as IPsec, but without the pain.

We have now reached the point where we can perform secure communications over the Serval Overlay Mesh, which is our implementation of this concept, using 256-bit Curve25519 public keys as network addresses, and with a defaults-secure Mesh Datagram Protocol.  This is based on the NaCl crypto library, and uses CryptoBox authenticated-encryption for unicast traffic, and CryptoSign verified signing for publicly readable broadcast traffic.

Curve25519 makes this feasible, due to the relatively short key length.  In contrast, using RSA we would need 3,072 bit keys for similar security (~128 bits of security).  Three addresses are required in each packet: source, destination and next-hop.  Using RSA 3,072 bit keys this would be 1,152 bytes — just for addresses.  Even using insecure RSA 1,024 bit keys the addresses would require 384 bytes. With Curve25519 we need just 768 bits (96 bytes) for addresses. We further improve on this through address abbreviation, where we only send the full addresses occasionally, and use a unique prefix the remainder of the time.  This allows us to reduce the address overhead by 75% or more, thus resulting in a lower address overhead than IPv6, but while gaining the attractive security properties that we have been talking about.

An important distinction between our MDP security layer and IPsec is that that we do not need any key exchange, as the keys are implicitly communicated since the network address is the key.  This is a luxury that IPsec could not make use of, because IPsec was required to be able to be retro-fit into existing IP networks with already-allocated addresses, and geographically allocated addresses.  MDP’s your-key-is-your-network-address only makes sense because geographically allocated addresses are not necessary (or even really possible) on a mobile adhoc mesh network.  Also, IPsec relies on third-party authorities to manage key exchange and related functions, and so is not suitable for use in an infrastructure-deprived setting.  MDP’s security is not client-server, but rather truly peer-to-peer.

The current state of the MDP security system is that it is operational, but requires some further refinement that we are undertaking, in particular to settle the API.  Nonetheless, it is already surprisingly easy to use MDP to enable secure communications.

So let’s see how this all ties together by taking a look at the MDP ping test program that we have written.  You can find the source code here as part of the Serval/DNA source on github. The vast majority of this example is in fact to perform the ping function and to report on errors (a common situation for network programming), the actual MDP networking primitives are no more complex than UDP.  So let’s take a look.

First, we need to bind to an MDP socket.  MDP uses 32-bit port numbers and 256-bit network addresses. A given node might have more than one network address.  As MDP is implemented as an overlay network, we must talk to the local MDP server on the node to perform all operations.  This is done over a unix-domain socket.  This has the advantage that it can be poll()’d, select()’d or whatever you prefer, just like a normal socket.  So let’s start by opening the connection to the MDP server and asking for the list of network addresses:

The remainder of the above code checks to make sure that no error has been returned, and that what the server replied with was in fact a list of addresses, as indicated by the packet type being MDP_ADDRLIST.

Once we have the address list, we can then use one of the local addresses to bind our listener to:

We know that the previous call to overlay_mdp_send has returned a list of addresses, and we know that a Serval overlay mesh node always has at least one local address, so we will assume in this example that the server response contains at least one address.  We then copy this address from the list of SIDs into the bind source address field.  We have to do this before we setup the rest of the bind request, because we are reusing the same overlay_mdp_frame structure, and mdp.addrlist and mdp.bind are part of a union that share storage space.  All that then remains is to provide the port number, and call overlay_mdp_send to request that the server make the binding.  If no error has occurred, the binding has been created, and can be used.

The remainder of the above code simply packs the source and destination addresses and payload (the server rejects any packets with a source address/port combination that has not been bound to), and sends it by the now familiar overlay_mdp_send function.  The next step is to watch for any incoming “pongs”:

This more or less says what we have been saying all along, but it moves the focus from the technology to the people using the technology.  At the end of the day, we are only making the technology in the hope that it can help people.


So we then turned to think about what the “minimum viable product” is for Serval, and we settled on a short-list of the four things that really matter right now.  These are the things that we are focussing our resources on, and not until those are under control will we move on to our longer list of things that we have on the drawing board (some of which I will describe later).


The four things that matter now are:

• ease of use – the Serval software must be easy and intuitive to use, otherwise no one will use it, irrespective of how great and innovative the technology might be. 
• resilient phone calls, messaging and file distribution - these are the core functions of the Serval software, i.e., what it let’s you do.
• strong, simple, security – security in mobile communications is so often an after thought, or severely compromised.  For example, the security of 2G and 3G mobile telephone systems has been thoroughly broken for years.  And when security is introduced into systems it has a bad habit of making life harder rather than easier.  Consider the complexity and interoperability issues suffered by IPSec as an example, indeed so complex that it’s security benefits go largely un-used.
• no infrastructure needed – this is what is needed to make sure that we can most effectively help those in need, as it is the failure or absence of infrastructure (or affordable access to infrastructure) that is a recurring characteristic of those we are trying to help.  Besides, there are already plenty of infrastructure-bound communications systems.

We are tracking well on these points, and expect to have positive news on the progress of several of these points over the next month or so.


Once we have these under control, we have a long list of features that we will immediately turn to, use-cases and improvements, some of which we are working on now in a limited capacity, and that we are planning support for from the outset. In no particular order, this list includes:

• broad device support - For now we are happy to support a limited range of handsets, but we know that eventually we need to support as wide a range as possible, including non-Android phones.
• Traffic prioritisation/QoS - Right now our focus is on making the core functionality as solid as possible.  We have plans in place for some innovative QoS functions that we will implement as resources allow.
• optimising battery life - The mesh can already run for a full business day on a cheap Android phone, but we want more. We want to get to at least 48 hours of continuous operation on a single charge, and ideally much more.
• massive scalability - Our protocols are designed with massive scalability in mind, but there are aspects of this that we simply don’t have the time or resources to implement right now.  We figure that it is more important to get it working at the “village scale”, and once that is right and larger networks start to emerge, it will be quite natural for us to complete our plans for scalability.
• privacy and plausible deniability – For some people they take their privacy seriously, sometimes because their lives depend on it, or because the lives of the people they are in contact with depend on it.  Eventually our software should make sure that it can be configured to not betray any such information.  This is a considerable technical challenge, and one that it is not even certain that it is possible to achieve.
• journalistic applications - This is intrinsically linked to the previous point, as one of the main issues for journalists is keeping their sources confidential.
• complex “crisis mode” of operation – By this we mean some complex modes of operation where a network of phones automatically detects that a crisis is underway using various network heuristics (such as loss of cellular service, correlated vibrations or loud noise over a wide area, and to take some hithero undefined appropriate action.
• group coordination – We have plans to introduce a variety of work-group/team features, that will allow ease of communications and coordination amongst small teams of people.  These are based on the core features that we are working on now, and so will be natural for us to complete once the dependent features are complete.
• global mapping system and services – We already have an effective prototype of our mapping application that we demonstrated recently, and that we will continue work on as we are able.  This is a feature that has us quite excited, because it allows for a wide variety of coordinated and crowd-sourced activities through allowing users to create and share points of interest on the map, and to even automatically share the map tiles over the mesh, creating something like Google Maps that works without the internet.
• environmental monitoring applications – We already have some projects in mind here that will make use of the mapping system to make it easy to collect, share and visualise environmental data in the field, and so hopefully help people assess and protect the natural and built environment.
• -medical applications - We are quite excited about the possibility of making a cheap medical device platform that uses a sub-$100 Android phone as it’s basis, combined with an open hardware port that allows the connection of an increasing number of off-the-shelf and custom medical attachments, such as pulse-oximetry, prick-less anemia testing, blood pressure, foetal heart-rate monitor and even imaging ultra-sound.  Support for additional functions and probes would be added to the platform overtime (with software updates over the mesh where required), as the interface would be open and flexible, doing to the medical device field what the smart-phone did to the software field. Extreme low-cost, field-upgradability, combined with resilient mesh communications to allow remote monitoring and collection of data and communication of alerts in infrastructure-deprived medical settings, we expect this concept to be highly disruptive to much of the medical devices space.

So that’s what we are thinking about right now.  But we invite your input to help us shape this as best we can, and also to help us achieve these goals if you want to be part of the action or to help us resource this work.

By: Torben Worm

The Serval Maps application started life as a prototype application developed to meet the requirements of my honours thesis in 2011.

I started by second honours degree in 2011, after not studying for 9 years, as a way to restart my career in research. I’ve been fortunate to be able to continue development of Serval Maps by joining the Serval Project at the beginning of the year.

Over the easter break this year it was decided to bring the Serval Maps application officially under the umbrella of the main Serval Project.

In the short term the only change is that source code is now hosted in a repository that is part of the Serval Project organisation on GitHub.

In the medium to long term it means that I can continue to develop the application, to which I’ve grown rather attached, as well as contribute to the main Serval Mesh application. It also means that users of the Serval Maps application in the future gain the support of the entire project.

I look forward to the exciting changes and opportunities that this change will bring.

The “Umbrella” photo was uploaded to Flickr by Torben Worm and used under the terms of a Creative Commons license.

By: Andrew Mason

The Serval Mesh application, to which I contribute when I’m not working on the Serval Maps application, makes use of a significant number of standard permissions when installed on an Android phone.

These permissions are used to gain access to either data or components of the Android operating system. For example to make and receive phone calls, or to access the external storage on the device.

In addition to these standard permissions the Serval Mesh application also requires the ability to undertake tasks using the elevated privileges of the root user.

This level of access is required to configure and manage the Ad Hoc Wireless Mesh network which is a core component of the software. Unfortunately Android doesn’t provide a standard way of configuring or using this type of network and so we need to use software at a lower level in the operating system to interface directly with the wireless network hardware driver.

Adding the ability to gain root access on a phone is typically known as “Rooting the phone”. Unfortunately there is some confusion about what rooting a phone within the context of the Serval Mesh software means.

This was highlighted for me recently when I read an article on the Computerworld New Zealand website.

The Wikipedia article for Rooting in Android OS states that:

Rooting is a process allowing users of mobile phones, tablet PCs, and other devices running the Android operating system to attain privileged control (known as “root access“) within Android’s subsystem. Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices, resulting in the ability to alter or replace system applications and settings, run specialized apps that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal Android user.

Once root access is achieved many users will choose to install a custom version of the Android operating system. One such popular custom version is CyanogenMod.

It is important to note that from the perspective of the Serval Mesh software it isn’t necessary to install a custom version of Android. For example my current development phone is a Huawei IDEOS X1 also known as a Huawei U8180.

I got mine from one of the local retail stores for one of the Australian carriers. It has a version of Android installed on it that has been customised by the carrier. The only change I’ve made to the operating system is the installation of software that supports root access using GingerBreak. There was a discussion about it on our developer mailing list at the time.

Just to be clear the Serval Mesh software requires the ability to run processes as root to configure and manage the wireless hardware of the device for use in an Ad Hoc Wireless mesh network. To do this the device must be rooted, however it isn’t necessary to have installed a custom version of Android.

The photo “Rooting my HTC Hero Android Phone” was uploaded to Flickr by Andrew Mason and used under the terms of a Creative Commons License.

It looks just like normal ping, except for those really long addresses (256 bits).  What is important for us, is that behind the scenes we have the Mesh Datagram Protocol (MDP) working, and all of the supporting infrastructure that goes behind it.

This means we are getting closer to carrying phone calls over MDP, and that is significant, because it lets us enjoy great transparent super-strong cryptography to protect the privacy of people making calls on a Serval phone.

It also lets us use non-IP based transports to carry the data, such as UHF and VHF radio based long-range mesh technologies that we are working on.  We are having some really encouraging conversations with one phone manufacturer about including UHF long-range meshing into their phones, which would be great, as it would provide hundreds of metres range indoors and potentially one to a few kilometres outdoors under ideal conditions.

Such improved range compared with WiFi makes mesh telephony much more useful, as it means that fewer mesh phones are needed in an area to allow communications to occur.  With WiFi you need someone in just about every house with a mesh node if you want to connect a community, because the range is about one house.  But the long-range meshing would increase that range to perhaps a 5 to 10 house radius.  In that context only a few percent of homes need mesh devices, which is much easier to achieve.

Meanwhile, I should get some sleep and then get back to writing software.

All the window-cameos from the old Batman TV series – Boing Boing.

* we have two labs – the small, windowless one is the Batcave, the larger, airier one is Stately Wayne Manor:)

Sonyas imploding 44-gallon drum – ABC Adelaide – Australian Broadcasting Corporation.