MeeGo Developer Community Grows As Software Ecosystem Support Broadens

The MeeGo project receives industry-wide support while it gets down to the business of writing code

SAN FRANCISCO, April 12, 2010 – The Linux Foundation, the nonprofit organization dedicated to accelerating the growth of Linux, today announced that companies from a broad range of sectors have committed to and are participating in the MeeGo project.

Participants today include leading device manufacturers, operating system vendors (OSVs), chipset manufacturers, independent software vendors (ISVs) and development communities. Supporting statements are attached from Acer, Amino, Asianux, Asus, BMW Group, Collabora, Ltd., CS2C, DeviceVM, EA Mobile, Gameloft, Hancom, Linpus, Maemo Community Council, Mandriva, Metasys, Miracle, MontaVista Software, Novell, PixArt, Red Flag, ST-Ericsson, Tencent, TurboLinux, VietSoftware, Wind River, WTEC, and Xandros.

This participation translates into millions of developer hours dedicated to cross-device compatibility, application portability and the user experience for MeeGo-based devices. Contributors are attracted to MeeGo because it extends reach beyond just smartphones to also include connected televisions, in-vehicle infotainment systems, netbooks and more.

The MeeGo project, which merges Intel’s Moblin™ and Nokia’s Maemo Linux-based platforms, was announced earlier this year at Mobile World Congress in Barcelona. An opening (http://meego.com/community/blogs/imad/2010/day-1-here-opening-meego-development) of the MeeGo distribution infrastructure and operating system base was made available last month, and the first release of MeeGo is expected in the second quarter of this year with applications available in both Intel’s AppUp Center and Nokia’s Ovi Store.

"The MeeGo project is being met with enthusiastic support from companies and developers who want to seize the market opportunity that exists for the next-generation of computing devices,” said Jim Zemlin, executive director at The Linux Foundation. "By working with a common set of tools and open technologies for building these devices, MeeGo developers will be able to easily reach the biggest addressable market available.”

As an open source software platform, MeeGo will help to reduce market fragmentation and complexity, while helping to accelerate industry innovation and time-to-market for next-generation devices, Internet-based applications, services and user experiences. MeeGo is designed for cross-device, cross-architecture computing and is built from the ground up for a new class of powerful computing devices.

Intel’s Imad Sousou, co-chairman of the MeeGo Technical Steering Committee and Nokia’s Ari Jaaksi, vice president of MeeGo Devices, will deliver keynotes at this week’s Linux Foundation Collaboration Summit on April 14, 2010. MeeGo project meetings will also take place on days 2 (April 15, 2010) and 3 (April 16, 2010) of the Summit. For more information about the Summit program, please visit:http://events.linuxfoundation.org/events/collaboration-summit/agenda

The Linux Foundation is a nonprofit consortium dedicated to fostering the growth of Linux. Founded in 2007, the Linux Foundation sponsors the work of Linux creator Linus Torvalds and is supported by leading Linux and open source companies and developers from around the world. The Linux Foundation promotes, protects and standardizes Linux by hosting important workgroups, events and online resources such as Linux.com. For more information, please visit www.linuxfoundation.org.

Trademarks: The Linux Foundation and Linux Standard Base are trademarks of The Linux Foundation. Linux is a trademark of Linus Torvalds. MeeGo is a trademark of the Linux Foundation. Moblin is a trademark of Intel.

In Russian

Mozilla's mobile Firefox browser is coming to Google's Linux-based Android operating system. Although the porting effort is still at an early stage of development, it is moving forward swiftly. Mozilla's developers achieved an important milestone this week by demonstrating that the browser can run on the Nexus One smartphone.

Due to the highly experimental status of the project, Mozilla has not yet published packages for testing, but that didn't deter us from getting our grubby mitts on the goods. As our readers know, we just can't resist the doughy flavor of half-baked software, and we will gladly brave the bugs for a chance to taste test the new hotness before it really heats up. In order to get our own hands-on look at Firefox on Android, we had to compile it from source code.

About Android and the NDK

Although Android is a Linux-based platform, it has its own totally unique userspace environment that is built on top of a custom Java runtime. Android applications are typically coded in Java and compiled into Google's own bytecode format so that they can be executed on Android's Dalvik virtual machine. Due to the somewhat insular and alien design of the Android userspace stack, porting a conventional Linux application to the platform is a highly complex and non-trivial effort.

Mozilla got the job done with Android's Native Development Kit (NDK). Developers use the NDK to compile C and C++ source code into native ARM binaries that can be loaded and used by standard Java-based Android applications. The purpose of the NDK is principally to make it possible for application developers to use native code for performance-critical computing tasks that would be impractical to perform on Dalvik. One of the secondary advantages of the NDK is that it allows developers to port and reuse existing C and C++ code.

Components that are compiled with the NDK can be used and integrated into an Android Java application via the Java Native Interface (JNI), a framework that serves as a bridge between a Java virtual machine and native code. Native code functions can be exported through JNI and made accessible to higher-level Java applications.

How the Firefox port works

To make Firefox run on Android, Mozilla modified the Firefox browser's Gecko rendering engine so that it could be compiled with the NDK and used in an Android application through the JNI.

Gecko is one of the core components of Firefox's underlying architecture. It handles parsing, layout, drawing, and much of the other functionality that is needed to display and support interaction with a webpage. In addition to rendering Web content, the Gecko engine is also used to render Firefox's user interface, which is described with an XML markup language called XUL.

Mozilla wrote a very small amount of Java code that is used as glue to make the native Gecko components accessible as an application in the Android environment. This code can be found in the embedding/android directory of the Firefox for Android source code. You can see how it works by having a look at the GeckoApp.java file.

The GeckoApp class is an Android Activity that handles the basic window layout and component initialization. The GeckoAppShell class loads the native libraries and starts running a Gecko engine in a thread. The GeckoSurfaceView class is an Android drawing buffer on which Gecko will render the page content and application user interface. The surface is embedded in the GeckoApp activity and painted to the screen. The surface is also responsible for relaying input events, such as screen taps and key-presses, to the underlying engine.

It's really important to understand that Gecko is used to draw the entire browser. In the Android port of Firefox, the menus, toolbars, and dialogs are all coded with XUL and rendered by Gecko instead of being built with standard Android widgets.

If Mozilla wanted to, they could build the user interface with real Android widgets and rely on Gecko solely for rendering Web content (an approach that is similar to the one used by Maemo's MicroB browser), but there are a number of highly compelling advantages offered by XUL that make it more desirable for a mobile Firefox browser. The principal advantage of using XUL for the mobile browser's user interface is that it is more conducive to supporting Firefox's much-loved add-ons.

One of the downsides of XUL as an independent, cross-platform toolkit, is that it doesn't automatically match the look-and-feel of other applications on any given platform. Mozilla compensates for this deficiency on the desktop by using the underlying platform's theming APIs to make the XUL widgets mimic the appearance of their native counterparts.

In mobile environments, Mozilla has taken a somewhat different approach with widget styles. Mozilla's developers have built a unique user interface with XUL that is tailored for small form factors and touch interaction, but doesn't necessarily bear a resemblance to the underlying platform. This tactic has delivered pretty slick results on Maemo.

This custom mobile interface hasn't yet been adapted for use by the Android port, however, which is currently using the same XUL templates as the desktop version of Firefox. This looks silly on a mobile device, but it's a temporary measure that is suitable for testing purposes at the present time. Mozilla says that the style that is used by Firefox Mobile on the N900 will eventually be used for the Android port.

Building the browser

For those who are wise in the ways of mozconfig, building Firefox from source is generally a simple matter. The process is almost entirely automated and requires very little operator intervention. If you are trying to do anything fancy, however, it can be a huge pain. Getting the Android port to compile proved to be a bit challenging. The port hasn't been merged into the main Firefox code tree yet, but it's available from a mozilla-droid branch that is undergoing heavy active development.

The Android page at the Mozilla wiki has some preliminary documentation, including a rough sketch of the steps that are required to obtain and compile the code. The instructions are a bit stale, so I had to improvise in a few places in order to get it to work.

You start by downloading the code from Mozilla's Mercurial-powered version control system. The next step is downloading and decompressing the Android SDK and the NDK. Mozilla had to make several minor changes to the NDK in order to get Gecko to compile, but they have fortunately published a patch on the Wiki page that you can use to apply their changes to your own local installation of the NDK.

Mozilla also helpfully supplies a set of build options that you can put in your mozconfig file. You have to customize the paths on the NDK and SDK lines so that it will know where to look for those components during the build process. You can ignore the section of the wiki page that explains how to build and run the JS/NSPR components—those sections are not applicable when you are compiling the entire browser.

Before you start compiling, you will need to set up a basic Firefox build environment. It's easy to do on Ubuntu, which has packages for all of the relevant dependencies. After you have everything set up, you run the make -f client.mk command in the top-level mozilla-droid directory.

This is when the hard part starts. The build process will periodically crap out and complain about missing bits. You will have to find and supply the necessary pieces in order to continue. I suspect that the exact things you'll need will differ as the code base evolves.

The biggest missing dependency seems to be the header files for Skia, the 2D graphics library that is used by Android. I had to download Skia's source code from its Subversion repository and copy the header files from include/core to mozilla-droid/widget/src/android. In the same directory, I also had to add copies of git://android.git.kernel.org/platform/system/core.git/include/cutils and git://android.git.kernel.org/platform/frameworks/base.git/include/utils.

After I provided those items, the build process made it all the way to the linking step, where it complained that it couldn't find -landroid_runtime and -lskia. I realized that those are Android libraries and was a bit surprised that the NDK itself doesn't include them. It's entirely possible that I missed a step at some point or failed to configure something that provides them. I ended up getting the necessary libraries from a live Android environment within the emulator.

The Android SDK comes with a tool called adb that can be used to interact with an emulated Android environment in various ways. The adb push and adb pull commands are used to copy files into and out of the Android environment. You can also use the adb shell command to get an interactive root shell for controlling the emulated platform. With the help of these commands, I pushed an executable of BusyBox into the emulator and used it to tar up the contents of /system/lib within the emulator shell. I used adb pull to get the tar file out and then I expanded it in android-ndk-1.6_r1/build/platforms/android-4/arch-arm/usr/lib. After I did that, the build process was able to finish successfully.

Under normal circumstances, you would test a Firefox build by running dist/bin/firefox-bin and generate a distributable tarball by running make package in the top-level directory. But that's obviously not going to work for the Android port. The final stage of the build process for Firefox on Android is compiling the Java code and generating an APK file, an Android installation package.

You can do that by going to the mozilla-droid/embedding/android directory that we discussed earlier in the article. All you have to do is run make in that directory and it will spit out your APK files. It will generate gecko.apk and gecko-unaligned.apk. Android has a tool called zipalign that optimizes packages for memory purposes. You are technically only supposed to use aligned packages, but I didn't really have much success getting gecko.apk to run during my tests. I was, however, able to successfully install and run the gecko-unaligned.apk package.

Running Firefox on Android

You can install Firefox into a live emulator instance by using the adb install command. The APK file itself is 15MB, but it uses roughly 53MB of space when it is decompressed. You have to make sure that your emulated Android filesystem has enough room to accommodate it, otherwise it will fail. You can do this by manually starting the emulator from the command-line and setting a high value for the -partition-size parameter.

After you install the package, you can run the program by clicking the GeckoApp item in the applications list. When the program runs, it will display a button labeled "Launch" in the top left corner of the screen. You can click this to start the actual Gecko process. There is generally some lag while it is getting everything set up. It doesn't consistently work and will sometimes crash before the actual browser starts. I had to try a few times before I could get it to work.

I wasn't able to get it to do much during my tests, but I was able to ascertain that it works. As the development is still at an early stage, it hasn't received much optimization yet. The performance consequently leaves a lot to be desired. It didn't seem to respond to keyboard input, but it was able to interpret my clicks. It's not very responsive at this point, so there was a noticeable delay between when I clicked and when it responded to my click.

I tested several features, including the bookmark system and page loading. To work around the lack of functioning keyboard input, I modified the Places SQLite database and added several sites to the browser's bookmarks. I was able to use those bookmarks to get the browser to load various sites that I wanted to test. It had no trouble rendering Ars Technica, but it couldn't manage the site's relatively modest JavaScript. The browser popped up a warning window prompting me to terminate the script because it was taking so long to run.

I really want to emphasize the fact that what we tested in this article is NOT a release, a prerelease, or an official build from Mozilla. I copied the code directly from the active working branch of a Mozilla developer and poked it with a sharp stick until I got it to compile. The purpose of this article is to shed some light on the development process and provide a helping hand to other enthusiasts who want to get it to compile. The bugs, performance issues, and other limitations that I've discovered are not indicative of what the final product will be like.

Firefox on Android is obviously not something that you would want to install and run on your handset today, but it has also clearly evolved beyond the proof-of-concept stage. It may not be practical to use yet, but it's a tremendously impressive feat that demonstrates Firefox's flexibility and illuminates the value and potential that can be unlocked by using Android's NDK. When it matures, it will bring more choice to users who are surfing the Web on Android-based devices.

More(RU)
Download Fennec (Firefox Mobile)

The smartphone market will slow to a 13 percent growth rate in 2009, but will rebound in 2010, projects Forward Concepts in a recent study. Forward Concepts also suggests that Linux's current share (11 percent) has been given a boost by the Android-based HTC G1 (pictured).

The "Smartphone & Chip Market Opportunities" study projects 13 percent growth in the smartphone market to 164 million units this year. The rate is down from 19 percent growth in 2008, but still better than that projected for most electronics segments this year, says Forward Concepts. The research group rather optimistically projects that smartphone growth rates will bounce back up again as early as 2010. Over the next five years, it estimates that the segment will see an overall 21.7 percent growth rate, to 387 million units in 2013.

Smartphone shipments. (Source: Forward Concepts.)

• Symbian -- 49 percent
  
• Microsoft Windows -- 14 percent
  
• RIM -- 13 percent
  
• Linux/Android -- 11 percent
  
• O/S X (iPhone) -- 10 percent
  
• Palm -- 2 percent
  
• Danger -- 1 percent

Smartphone units by vendor share. (Source: Forward Concepts.)

• Digital basebands
  
• RF transceivers and PA's
  
• Communication processors
  
• Application processors
  
• Graphics
  
• Multi-touch screen controllers
  
• Memories
  
• Specialty chips for:
  • Camera sensors
    
  • WiFi
    
  • Bluetooth
    
  • FM
    
  • GPS
    
  • Mobile TV
    
  • NFC
    
  • Fingerprint sensors
    
  • Accelerometers

Icop has announced a little panel PC built around the company's own 32-bit, x86-compatible SoC (system-on-chip). The PDX-057T has a 5.7-inch touchscreen display, 256MB or 512MB of RAM, CompactFlash Type I/II and microSD storage, and a Mini PCI slot, according to the company.

(Click here for a larger view of Icop's VDX-6354)

The new PDX-057T employs Icop parent company DMP's Vortex86DX SoC (right), announced in November of last year. The Vortex86DX is built using a 90nm process, comes in a 27 x 27mm package, and is said to use under two Watts while running at up to 1GHz.

The Vortex86DX is said to include the complete 486SX instruction set, adding floating point support. Unlike DMP's previous Vortex86SX, the SoC is capable of running Windows XP and Windows XP Embedded, has 256MB of embedded L2 cache, and supports up to 1GB of 33MHz DDR2 memory, according to DMP.

Icop's VDX-6354 module also uses DMP's Vortex86DX (Click for details)

The Vortex86DX SoC doesn't include an IGP (integrated graphics processor), though DMP added VGA to its subsequently released Vortex86MX. We suspect that Icop has given the PDX-057T VGA capabilities using a separate XGI Volari Z9s chipset, just as it did on its recent VDX-6354 PC/104 module (right).

In any case, Icop's little panel PC (5.98 x 4.41 x 1.3 inches) is said to offer 640 x 480 resolution on a 5.7-inch resistive touchscreen display. The device is offered with either 256MB or 512MB of RAM, while storage is via CompactFlash Type I/II and microSD expansion slots, both externally accessible.

The left and right sides of Icop's litle PDX-057T
(Click on either to enlarge)

• Processor -- 1GHz Vortex86DX
  
• Memory -- 256MB or 512B of DDR2 RAM
  
• Display -- 5.7-inch resistive touchscreen display with 640 x 480 resolution and 300:1 contrast ratio
  
• Storage -- Includes CompactFlash Type I/II and microSD slots
  
• Networking -- 10/100 Ethernet
  
• Other I/O:
  • 3 x USB 2.0
    
  • 1 x RS232
    
  • 1 x PS/2
    
  • Audio line out (optional)
• Expansion -- Mini PCI slot
  
• Operating temperature -- -5 to 60 deg. C (23 to 140 deg. F)
  
• Power requirements -- 5VDC (PDX-057T-5) or 8VDC to 35VDC (PDX-057T-8)
  
• Dimensions -- 5.98 x 4.41 x 1.3 inches (152 x 112 x 33mm)
  
• Weight -- 0.82 pounds (374g)