This is by far one of the most balanced studies I’ve seen comparing successful (and unsuccessful) well-known open source projects. Incidentally, visionmobile’s clients include HTC, Sony Ericsson, RIM, Microsoft, Intel, etc as part of it’s well known client lists.

Their quantification of “openness” between selected mobile open source projects (both successful and unsuccesful, single sponsor and multi sponsor) is called as the “Open Governance Index”.

The results were particularly interesting:

Among the 8 open source projects listed, Eclipse was the most “open” of all the projects, and Android was the last in the list. The research paper however noted that Android is also one of the most successful projects in the history of open source. It was contradictory enough that the paper called it the “Android Paradox”.

A number of interlinking factors were cited what made Android successful:
1. Google’s financial muscle and marketing.
2. Android’s “zero cost” subsidy by Google, since Google’s ultimate purpose is to drive more eyeballs to it’s ad inventory, which results to cheap handsets and low cost internet connectivity.
3. The adoption of the Open Source project by different manufacturers in order to compete against Apple’s iphone. The OEM industry generally poured billions of dollars into Android in order to compete with the Cupertino company’s product.

In retrospect, the research paper acknowledged that in the long term, platforms with the most open governance will be the most successful. Cited success stories are Eclipse, Linux, WebKit and Mozilla. Meego has the capability to become a successful project in the long term, in my opinion.

It also went to suggest that making a project open doesn’t necessary warrant a successful community builder. They stated that Software developers are human in nature and self-centered; and will only take interest in such a project if it provides value or addresses a common need – citing Linux, GTK or Webkit as an example (need for a vendor-neutral operating system, graphics software stack, browser engine). Symbian failed in this aspect; they failed to target developers (besides this, no proper development tools, complex contributions structure, etc).

What does this mean for Android and competing open source projects such as Meego?

Android was successful because aside from the factors stated above, when Android was released to the developers, the product was already a very advanced, and complete project (by and large due to Google’s famed engineering team):

However, there are some very good lessons for us to learn from how Google has managed the Android
open source project. First, Android was released as an open source project at a point in time where it
was already a very advanced, complete project. OEMs, operators and software developers could more
or less immediately use it to create derivative handsets and applications. Second, Google kickstarted a
developer buzz around the project with the $10 million Android Developers Challenge. Alongside
financial incentives, Google provided a very strong emotional message: that of opening application
development within a previously inaccessible mobile industry. Finally, Google’s speed of innovation
(five platform versions across 2010) outpaces any external innovation, and makes the ecosystem
entirely reliant on Google.

On the other hand, when Meego was announced, it was basically starting from scratch (okay, not exactly scratch, but the earliest versions of Meego were in the command line from my perspective) – try to imagine that they essentially went from a deb-based packaging solution (Maemo) to an rpm based one, and shifted from GTK/clutter to mainly Qt. This was one of the disadvantages I saw with the early development of Meego, and I have to say most likely hampered it’s early adoption (I do like the very open way the meetings are held though – I’ve been in one of the developer meetings in the past; but due to time zones it’s really difficult for me to attend it). It has gotten way better though; with the inclusion of non-Nokia/Intel people into the upper build team, the development process is getting to a point where I believe that this operating system will likely pick up pace and steam in the very near future (it has a bright future ahead in IVI systems in vehicles for example, and the upcoming N9 is positively received by many).

Now, let’s look at the actual php code that will make the spelldial call based on what your android spelldial app will send:

You can save this code snippet in a file named droidspell.php:

include "spelldial.php";
$spell = new Spelldial();
$result = $spell->get_info($_POST['spelldial'],$_POST['calltype']);
if($result->error_code !== '0')
{
die("error");
}
echo $result->content[0]->info[0]->uri;

This is a typical use of the spelldial class I made (this uses post variables spelldial and calltype, ie. tel or skype to determine what to return as output to the android application).

Now for the html code snippet:

<script src="jquery-1.4.2.min.js">jquery-1.4.2.min.js</script>
<form id="spellform" name="spellform" method="post" action="http://yoursite/droidspell.php">
<table width="300" border="0" cellspacing="0" cellpadding="0">
<tr>
<td height="27" colspan="2">SpellDial Name</td>
</tr>
<tr>
<td height="31" colspan="2"><label>
<input type="text" name="spelldial" id="spelldial" />
</label></td>
</tr>
<tr>
<td height="42" colspan="2" valign="top"><label>
<select name="calltype" id="calltype">
<option value="TEL">Telephone</option>
<option value="SKYPE">Skype</option>
</select>
</label></td>
</tr>
<tr>
<td colspan="2"><label>
<input type="submit" name="dial" id="dial" value="Call me using SpellDial" />
</label></td>
</tr>
</table>
</form>
<script>
$("#spellform").submit(function(event) {
event.preventDefault();
var $form = $( this ), spelldial = $form.find( 'input[name="spelldial"]' ).val(), calltype = $form.find( 'select[name="calltype"]' ).val(),
url = $form.attr( 'action' );
$.post( url, { 'spelldial': spelldial, 'calltype': calltype },
function( data ) {
if(data == 'error' || data == '')
{
alert('Spelldial API returned an error: '+data);
} else {
location.href = data;
}
}
);
});
</script>

As you may see, this is typical html form/jquery event code to get the result of the droidspell.php call and then determine if an error occurred and if not, go ahead to the android dialer to make a call.

You’ll see some stuff like jquery-1.4.2.min.js in the code above. Where is it placed? It is placed where the index.html is placed in the assets/www folder:

If you want to use the phonegap wrapper functions place this snippet in the <head> portion of your index.html file:

<script type="text/javascript" charset="utf-8" src="phonegap.0.9.6.js"></script>

You may rename phonegap.0.9.6.js to phonegap.js if you wish.

This is how a finished phonegap application looks like in the emulator (yeah yeah, ugliness noted, I made this quickly!):

Once you see this application running in your emulator, you might want to package this application into an apk. Simply right click on your project in the project window and select Android Tools->Export Unsigned Application Package – once you follow the instructions, this will create an unsigned apk file for you automatically.

You can also create signed apk files for distribution into the Market. For further reference, please see http://developer.android.com/guide/publishing/app-signing.html for details.

And there you have it, we have now made an android application in phonegap using the spelldial php class, tested it in an emulator, and published it as an apk file.

Let’s try to make a simple Android application using the phonegap cross-development framework calling a php script that uses my spelldial class to return a spelldial uri. Part one will describe steps on how to make your very first native webapplication in android (simply a hello world android web application).

I assume that you know how to install eclipse, the android sdk and the phonegap framework on your system (I’ll cover this in small detail, to help you get started).

There are many ways to program in android, ios, symbian, blackberry or winmo phones. There are cross-development frameworks which give you an abstract way to program in these mobile devices without dealing with the underlying phone hardware.

Two different technologies come to mind (these are the most popular that I’ve seen):
1. Appcelerator Titanium – this cross development tool allows web developers to quickly go into the mobile application department using what they know. HTML5, CSS, and a host of web programming languages such as php and ruby are supported. What is unique about this SDK is that these technologies are then compiled into their native counterparts – the end result is a native application. Impressive, actually. Supports both iOS and Android environments.
2. Phonegap takes a different approach. This is closest to what you call as a web application encapsulated in the mobile phone’s browser class. For example, what this means, in Android, this framework wraps around the WebView Java class and makes certain native phone functionalities available (like accessing your contacts for example) through javascript. For flash/flex developers, this is much like the ExternalInterface class that bridges between javascript and the flash application.

Which is more appropriate? If you’re a web developer and would like to make your application as close as possible to a native application, your best bet would be Appcelerator.

Why am I using phonegap in this case? If you just like to quickly develop applications and do not care if they look different from native applications, use phonegap. By the way, because of how phonegap works, it is available to more mobile environments than Appcelerator. Symbian, WinMo, Blackberry, iOS and Android mobile environments are supported by phonegap. No matter what the environment, your application would look the same because it is just practically your html application enclosed in the native phone’s browser class.

Also, phonegap is supported by the Dreamweaver CS 5.5 release, which means if you can afford it, mobile development will be quite simple to do (without using Eclipse as your environment to develop phonegap applications).

Now, lets begin. Let’s create a new project in eclipse by selecting File->New->Other

We now include our details for the application (Since Froyo or Eclair, the android version before 2.2, runs in 86% of android phones, I choose the lowest common denominator, Eclair), below:

We will have to add the phonegap jar file to the libs folder (which you will have to create) and also create the /assets/www folder where you will place the html files for your application. In this www folder, you will have also to place the phonegap.js file in there. This js file contains the functions that you will call to access native mobile phone functions such as accessing your camera, contacts, etc.

In order for Eclipse not to spurt out an error message (having a java class not available for use), we have to add phonegap.jar to the Build Path (Right click on the libs folder, select Build Path->Configure Build Path):

We will now edit the spelldial.java source code which was created using the New Project Wizard to look like this:

Let’s look at it line by line:

import ...
import com.phonegap.*;

The code above imports the phonegap class for use in our application.

public class spelldial extends DroidGap

Our spelldial class (which was created by the Wizard), extends upon the DroidGap class, which is in fact an extension of the WebView class.

This line below is what runs the web application (sort of like the main() function in your c program):

super.loadUrl("file://android_asset/www/index.html");

You can change the url to whatever you have placed in the assets/www folder as your starting point. index.html can simply be text saying “hello world” at this point.

One more thing, since phonegap uses certain native phone functions which require explicit permissions for the app to run, we’ll have to edit our AndroidManifest.xml to allow our app to use these:

These tags are placed below the android:versionName section:

<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true"
android:resizeable="true"
android:anyDensity="true"
/>
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.VIBRATE" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.RECEIVE_SMS" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

And there you have it, some basic steps on how to set up the phonegap framework in eclipse. Part 2 will be the actual js code and php code that this web application uses to call a person using the spelldial api php class hosted on a server.

To end this, let’s take a look at phonegap support in Dreamweaver CS 5.5:

When I was young, I was fascinated with hardware and programming low-level stuff to do something nice as an experiment.

I got into programming DOS programs in assembly language (8086). In school, I was fascinated with 6502 assembly language (which wasn’t really that far from 8086, the concepts were mainly the same). As an Electronics Engineer student, my hardware thesis involved creating a hardware interface that detects acidity (pH) in soil with the added twist that it was plugged into the printer port (yes, PCs had parallel ports back in the day) and a program interprets the values that was in the printer port and records them. And yes, the program was in Visual Basic (shocker, right? An unusual use of the Evil Empire’s program environment).

Even friends from the Computer Engineering class asked my help in developing their computer interface projects (which included a voice recognition project for security and a vending machine – which detects what money was inserted into the machine).

One may ask… OK, you’re talking about the past, what has this got to do with Linux?

Let me give you an opinion that will be a shocker to you… Linux might never make it big into the desktop.

Let me start by telling you my experience with Linux. Don’t you get picky with me saying that Linux is the kernel. I am familiar with that.

I started delving into Linux when I was a sales agent of an isp. During that time, all of us sales agents have 8 hours of free internet (dial-up). I started into connecting my 33.6kbps modem through trumpet winsock and downloaded my first linux distribution: Monkey Linux. From that time on, I was hooked. Tried other hobby linux distributions (trilinux, looplinux, etc, settled for a few years with peanutlinux and gained quite a number of friends in the forums), and for a number of years, I was happy. I became an open source advocate. I remember downloading the 100Mb peanutlinux distribution for almost a day (dialup, whoooopeee). I brought linux into a company I worked for as an instructor (before that, I taught short courses for people like MS Office, and Basic computer instruction – I remember teaching a group of PLDT operators, yes operators, the ones that answer the line when you call 109 or 108 for long distance dialing). As I developed instruction modules for Visual Basic, I developed instruction modules for Linux (made even a mod of Peanutlinux, with Jay’s help in giving instructions, called Berkeley Linux, for internal use and passing on to students of the courses) – complete with Gnome environment (1.x at that point), and with WINE, to run some windows programs like winamp on Linux. As usual, I included Xitami and php in the mix of that mod, as standard.

I even got to create instruction modules for OpenOffice (then 1.x); but before that I used StarOffice 5 (when the license was not GPL, but rather free for non-commercial use).

Then reality set in. At first I didn’t mind it. Sound issues. Graphics issues. Wifi and network issues. I simply moved from one distribution to the next (PCLinux, Ubuntu, Mint, Fedora, and currently my laptop distribution, Meego).

And you know what? Even until today, these are still issues!

So, what’s keeping Linux from ever conquering the desktop? A big issue are drivers.

I love linux, don’t get me wrong. Don’t ever accuse me of being an troll – as you’ve seen on my blog, I dig linux.

However, one thing I’ve noticed is that the API for drivers is virtually non-existent. At least with OSX, they have a framework for extending or creating drivers (usually in userspace). Windows has also a framework for driver development (take your pick, WDM, vxD for older version of windows, etc)

When you update kernel versions, you have to recompile your drivers. Yes, I know, there is dkms. I’m not talking about that.

Linux simply has no formal frameworks for drivers. There was an attempt by Intel before (1998 to be exact), to create a framework named UDI, but was dissed upon by Richard Stallman and open source advocates. An excellent point for UDI was given by a former developer in this forum post.

I am a pragmatic person. I use whatever tools are necessary to get the job done. And that means using windows if that gets the job done – I would’ve preferred using open source, but if there is no software equivalent in linux (which is usually the case, unfortunately), I use windows or osx. Looking back, that decision in my opinion would fit in the category of boneheaded decisions of the open source community.

Linux advocates have a NIH syndrome. Instead of using stuff that works, they create a new one, usually REALLY buggy.

Case in point: pulseaudio. A big heaping piece of dog poo. Well, it has gotten better, but the latency issues are soooo annoying.

Yes, useability has gotten better, but when suspend/hibernate issues still exist even today, and wifi issues still exist, there is something definitely wrong. A friend of mine bought a laptop and installed Ubuntu, or Mint on it, and found out it didn’t work. Tried other distributions, didn’t work too. He almost gave up, but was lucky enough to get some instructions from friends who instructed him to get some firmware code through his driver cd and some command line stuff. I was even surprised by this even today, broadcom drivers are an issue (despite having broadcom-wl drivers and bcm driver stuff already).

Even my meego laptop, the lcd brightness control doesn’t work. And I had to compile OpenVPN for it myself (which reminds me, I’ll have to compile the newest OpenVPN and upload to the repository, when I get the time).

The list goes on and on. Enough of my rant. I’m an old guy. My experimentation and tweaking with the OS days are getting to an end (real life has come in – need money to pay my bills). I just need something that works.

Just to end (almost), I’ll give you some pseudo-code for a harmless virus I made as an experiment to learn how DOS works (this simple non-overwriting .com program became my thesis for a fifth-year paper on computer viruses – I created this experiment during my summer vacation in second year college).

Ordinary pseudo-code for a typical .com program:

jmp code
[data]
….
code:
….

My assembly code:
jmp [viral code]
[original data]
…
[original code]
…
viral code:
check if it is already resident (calls a modified int 22h hook with subfunction to see if it is installed)
if(not installed)
move viral code above DOS program memory
call int21h function to modify interrupt table to chain int 21h to viral code
edit 3 bytes at the beginning of the program to the original code
jmp [beginning of code]
[int 21 viral code]
…

Sounds unconventional, right? But this experiment I made in college helped me a lot in how OSes and computers work. DOS was excellent during that time because they provided a unified API – if I used purely assembly code and manipulated IO/Disk hardware registers directly, my code would have gone way over 1000 bytes (and wouldn’t have worked on all computers at that time) – even using an int13h bios code function would be more complicated to do. After all, it was all about developers. I would like to thank Ralph Brown for his excellent DOS Internals book (duh)! With this knowledge incidentally, I was able to make an anti-virus program in Turbo Pascal for the Tadpole virus (created by some students in another university) during my third year college.

If only linux had a unified driver interface, plus a unified media interface, and graphics interface with frameworks, then it would have leaped above windows and osx. Unfortunately, with the state linux is in, and the bickering and infighting of different groups in them (and misguided open source fanaticism), I really doubt linux will ever reach mainstream status (maybe android and chrome os).

Enough of my rant. What do you guys think? Am I a grumpy old man? Or do I talk sense?

1. Download OpenVPN Installer and OpenVPN Settings from the Market.  If you don’t have tun.ko yet download the module I compiled for kernel 2.6.32.9 ARMv6 devices from here.
2. Run OpenVPN Installer (openvpn should be installed in /system/xbin, and ifconfig path in /system/xbin/bb).  /system/xbin/bb is not available yet, we’ll get to it later.  For roms like Bakpia Keju which do not have route and ifconfig busybox links properly installed, do the following in the terminal:

   adb shell
bash
cd /system/bin
ln -s /system/xbin/busybox cp
ln -s /system/xbin/busybox chmod
ln -s /system/xbin/busybox route


3. Use a barcode scanner (available in the market) to read the barcode below:
   
4. Paste this code in SL4A application (also available in Skyfish).  If you’re not in Skyfish, make a script named openvpn.sh and paste the text from the barcode in there.  Save and run the script.  This should make the proper route, ifconfig and busybox binaries be symlinked to make the OpenVPN Settings run properly.  If you like to use SL4A, you can download the application from here.

Your openvpn is now configured properly and should now work as expected.

I just happened to watch a youtube video of the Android mascot dancing to a spiffy beat. I don’t know about you, but I found this awesome!

Enjoy the vid below:

This is tested in the Bakpia mod kernel (2.6.32.9), module compiled from the rmcc github kernel 2.6.32.9 branch located here.

Compiled in a CentOS 5.3 environment with android ndk and sdk installed.

Anyways, copy the module to /system/lib/modules do an insmod tun.ko to run the module and tunneling is all set. You can now use Openvpn downloaded from the Market.

Download here.

For those who want to compile a tun.ko kernel for Android (a commtiva z71 variant), here are the general steps. You need a linux environment to compile this module.

1. Download the kernel and supporting files for commtiva z71 devices here: https://opensource.motorola.com/sf/frs/do/viewRelease/projects.quenchxt/frs.xt5.xt502 and extract it to a directory of your choice.
2. Download the SDK and NDK for android: http://developer.android.com/sdk/ndk/index.html and http://developer.android.com/sdk/index.html
3. Copy config.gz from your phone and place it into your kernel source folder. To get it from your phone, type:
adb pull /proc/config.gz .
gunzip config.gz
mv config .config
4. Edit .config so as TUN module will be included into the kernel:
CONFIG_TUN=m
5. Run uname to get running kernel version of your phone:
uname -a
Linux localhost 2.6.32.9 #7 PREEMPT Tue Jan 4 16:51:45 CST 2011 arv61 GNU/Linux
6. If there was some extra characters in your kernel version, like 2.6.32.9-063c4d24, you’d have to edit the Makefile to use the corresponding version:
EXTRAVERSION = -063c4d24
7. Set your environment variables:
export ARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=$PATH:~[path of your arm-eabi compile toolkit binary in android ndk]
8. cd to your kernel folder and make modules
cd ~[path of your kernel source]
make modules

Resulting tun.ko should be in the drivers/net folder of your kernel source.

Just beware, it is not for the fainthearted.

Further information:
http://android-dls.com/wiki/index.php?title=Build_a_custom_kernel
http://forum.androidcentral.com/htc-hero-rooting-roms-hacks/8072-how-build-your-own-kernel-package-source.html

I did this on my Cherry Mobile Nova, but basically all android phones have similar settings screen.

Facebook Zero is a service by Sun Cellular offered to its subscribers to access the popular social networking site for free (by now). Let us see how to configure this currently free service for android devices.

We need to make sure that the Sun wap APN is configured on the Settings->Wireless & Networks->Mobile network Settings->Access Point Names as shown below:

If its not created yet, let us create a new APN called “Sun GPRS” (screenshot below shows the important settings used for this wap service):

Select this APN for use and on the previous screen, enable Data:

This will let android connect to the wap service. Let us now open the default android browser and type in “0.facebook.com”:

If successful, you will now connect through the browser (through wap) to facebook for FREE. Happy surfing!

Thoughts about it? Really cool, but android by itself is somewhat unpolished compared to iOS, or even Symbian for that matter.

Stay tuned for more.

Posted from android.