There is a not so uncommon misconception regarding open source software where people apparently are mislead by the word “open”. Open source means exactly what it sounds like – the source is open and available to you. That does not however mean that the end-product is open and “hackable” in every way.

Sure, the source being available helps in a lot of scenarios, but it doesn’t always give you what you want. Now for instance if I am dabbling with a new Windows Mobile device, and there is some setting I want to be able to control (other than the button in the GUI), I might go looking in the file system or the registry for clues. Some times I end up looking at a file, (say for instance a .dll), that I have a pretty good clue is responsible for what I’m looking for, but I don’t find a way to control the feature outside of this file. And in cases like this it would be nice to be able to have the source of the file, and being able to learn how to do it by reading some code. True, if the application is written in C# it’s pretty easy to do a “reflection”, and re-build most of the source that way. If it’s written in C++ it’s more hassle, but you can still reverse engineer it some way. But whether you like it or not that’s just the way a lot of software is provided to you, and you usually have to rely on solid documentation to be able to do all the things you desire. (Or rather “all the things you are supposed to be doing” according to the application provider.)

Now, I don’t intend to start a new religious war, bringing up the old Linux versus Microsoft debate all over. Let’s just say open-source and closed-source are different approaches to delivering software.

I mentioned previously that I have been playing with an Android device, and quite liked parts of it. And the Android is Linux-based, and open-source based. So is the Android platform open for managing too? I’ll try to provide a very brief overview.

Google has based themselves on the Linux kernel, and together with some partners (like for instance HTC) have created their own distro. In addition to having devices with Android pre-compiled (would be sort of useless having to compile it yourself after walking out of the store I guess), you can download an SDK, the source itself, modify it, and re-compile to your liking. And at least theoretically you are able to build your own mobile device. (Needless to say there are some more minor challenges to making your own mobile than just an OS.) Most people will be more than happy to just buy ready-made devices, and adapt these to their needs though.

But it’s important to understand that when you buy a device, like the HTC Hero that I tested, it’s not “pure” Android. It’s the HTC flavour of Android. You want to sync with Exchange? Additional software provided by HTC. You want to connect to a desktop computer and transfer files? Additional software provided by HTC. If you ran the Google version it simply would not be there. (Yes, there might of course be an element of political motivation on Google’s side too for not providing these features, but that doesn’t help you as an end-user.)

In traditional Linux terms I guess it’s a sort of “fork”. I do not know if the HTC-compiled version is different enough from the bits provided by Google to qualify as a proper fork – probably not since Google and HTC are working closely together. If you are not familiar with the term fork it basically means a different branch of Linux. For instance while Debian and Red Hat both are Linux-based operating systems, and have common traits they have chosen different directions, and software compiled for one might not work out-of-the-box for the other.

With the backdrop set, how do you go about managing an Android device?

Android uses the concept of application signing, much like the other major mobile operating systems. It does not require all applications to be signed by Google however. You can use self-signed certificates if you so like. (The certificate chain is not validated, it’s used to authenticate the application itself.)

Each application will be allocated it’s own memory space, and will not be able to mess around freely with any other application’s memory. If you as a developer have more than one application, and make sure to sign them with the same certificate, Android will be able to figure out that your applications might want to share some info between them and allow cross-application access. So obviously this would be the first obstacle you’re facing regarding device management.

Well, we can appreciate applications not disturbing each other. But configurations and settings aren’t necessarily allocated in memory so maybe there’s a way around this issue. On Windows Mobile we mainly use the registry for storing configuration data. Or .ini/xml-files. Not so here. Well, ok, you can create your own xml files if you sit down to code an app I guess, but the standard/recommended method is small databases containing the metadata. So you need to figure out how to parse the db, sort out the tables and columns, etc if you want to know what metadata the application uses. You’ll probably figure this out if you hook up an emulator and grant yourself root access. Unfortunately initial tests indicate that even root will not give you write access to the databases if you didn’t sign them. (What’s the point of root if you can’t “own” everything…)

So I guess that means hands off other apps in general.

How about basic stuff like power-on-password, encryption, etc. Well… There are no built-in facilities for this. It is possible though to create your own PoP. (It would basically be just another app, which just happened to be a power-on-password program.) Other system settings like GPRS? Prime candidate for OMA CP/DM. Which isn’t currently supported either so you’re out of luck there too.

How do you actually manage Android devices then? I must admit I wonder too. Third-party apps have become available, and some provide what they call device management. But, we’re still lacking some serious options. I know several MDM vendors are working on it, but it seems they are running into challenges as well. (If it was a breeze we surely would have seen some fancy stuff by now.) Oh, well, I have plenty of source code just sitting here, and a lot of spare hardware. I’d surely be out of luck if the source had been proprietary

I don’t remember if I have mentioned the irony of the market space for mobile operating systems before – but Microsoft is still the most “open” alternative when it comes to being able to modify the stuff that comes out of the box. It must feel bad for the most ardent Linux fans out there, but your platform of choice is the restrictive one. (/Ironic observations: I still believe there are some really nice features in the OS design of the Android, but even though version 2 of Android is right around the corner the platform has not reached the same level of maturity as Windows Mobile has.)