Firefox 8 for Android is now being built with NDKr5. Bug 657723 tracked deploying the updated NDK to our build slaves and updating the configuration to use it. After a couple of hiccups along the way we started producing on change builds with it on Wed July 27th and the first NDKr5 built nightly went out the following Thursday. We will build Firefox 6 and Firefox 7 with NDKr4 as we want to get a full development cycle’s worth of testing with the new toolchain.

This is important for a couple reasons. First, it gave us some nice performance improvements. I’d love to show you some nice graphs that illustrate that, but our data is so noisy that it depresses me. Anecdotally, several Mozillians have come on the #mobile irc channel in the last few days to comment on the improved snappiness they’d noticed over the weekend.

But, the biggest thing for me is that you can now build Firefox for Android using a stock NDK. Previously you had to use our custom built NDK (which was built on the crystax NDK) to support the usage of STL in Mozilla. This should make it much easier for your casual Android developer to drop in and contribute to Firefox on Android.

To get started building Firefox for Android with NDKr5, check out the build instructions here. Or if you want to get started a little more quickly, you can grab the development VM I posted about.

About a year ago I posted a VMWare VM that had been set up to build Fennec for Android. That was still pretty early in the development of Fennec for Android and things have changed a lot since then. In particular, we now support developing with a stock NDKr5 (or NDKr6). So, I’ve created a new VM with these updated tools and an updated tree, which can be found here.
We’ll be moving to NDKr5 for our production builders as soon as we can resolve some issues we have with our testing automation. You can follow that progress with bug 657723

Since we switched to the rapid release process, the mobile team has been using tracking-fennec to track bugs we care about for a particular release (so that tracking-fennec=7+ means the patch or feature either landed in Firefox 7 or we expect it to). Yesterday we added another possible value to that in just a plain plus (“+”).
The motivation for this change is that there is a set of bugs that we know we care about and want to keep “on the radar” but that we can’t say with any certainty will land in a given release. When we get more clarity on that we can change the tracking flag to reflect that new information.
Since we’re not tracking the bugs marked tracking-fennec=+ for a given release, the drivers won’t be as religious about finding assignees for them. So if you’re looking for something to work on, have a look at the queries listed under “Bugs to pick up” on this page. They are essentially open, tracked bugs and unassigned, open tracked bugs.

The changes required to build Fennec for Android with NDKr5 have landed. Up until now you had to use a custom built version of NDKr4 that included STL support (based off of Crystax’s NDK). Now with NDKr5, you can build Fennec with a stock NDK.

There’s also a performance benefit. We’ve seen a significant performance improvement in many areas from the updated toolchain. However, there is a fairly significant performance regression from JIT’d code that prevents us from switching over to the new toolchain right now. That regression is being tracked in bug 658074 and once it is resolved we’ll turn it on for the automated builders.

If you want to build with NDKr5, you’ll just need to make a couple changes to your mozconfig. Here’s the one I build with:


# Add the correct paths here:
ac_add_options --with-android-ndk="/home/blassey/android-ndk-r5"
ac_add_options --with-android-sdk="/home/blassey/android-sdk-linux_86/platforms/android-8"
ac_add_options --with-android-version=5
ac_add_options --with-android-tools="/home/blassey/android-sdk-linux_86/tools"
ac_add_options --with-android-toolchain="/home/blassey/android-ndk-r5/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86"
ac_add_options --with-android-platform="/home/blassey/android-ndk-r5/platforms/android-5/arch-arm"

# android options
ac_add_options --enable-application=mobile
ac_add_options --target=arm-linux-androideabi
ac_add_options --with-endian=little
ac_add_options --enable-debug-symbols
ac_add_options --with-ccache
ac_add_options --disable-tests
ac_add_options --enable-crashreporter
ac_add_options --disable-elf-hack


This key changes are obviously the paths and changing the target to arm-linux-androideabi.

Special thanks to Alon Zakai for nailing down the last few issues that were stumping me.

Most Android keyboards show what’s called an “extracted text view” when they’re in landscape mode, where it takes over the whole screen hiding the underlying application. However, you can use the EditorInfo.IME_FLAG_NO_EXTRACT_UI flag with your InputConnection to tell the keyboard not to show the extracted view.
The stock browser now does this (see the source) since Froyo, and you can see it in action by clicking on the search box on google.com in landscape mode. You can see that the stock browser pans the search box such that it is visible just above the keyboard. It looks like the stock browser resizes their view since you can pan to the bottom of the page within that little space above the keyboard (see screen shots).

What I’ve been trying unsuccessfully to figure out is how they’re getting the visible area (or perhaps, inversely, the size of the keyboard). I don’t see any API on the View, ViewGroup, ViewParent, InputConnection etc. that will give you that information. Can anyone help?

Search box visible above landscape keyboard

Panned to the bottom of the page (search box still focused)

There are many things that can fall into the broad category of “performance.” The flavor of the month, as of late, has been “JavaScript performance,” perhaps because it’s so easy to get numbers from various test suites that can be used to compare browsers. The major advances that browsers have been making in the last few years enable a whole class of web apps that were previously unthinkable.

But we care about many other things that could fall into the performance bucket, like the time it takes the browser to start up, which has an obvious impact on the user’s experience, especially on mobile where the browser tends to start and stop more often than desktop. Another fairly obvious performance metric is page load speed, something the user will see feel every time they use the browser.

Besides measuring how long things take to happen, we also care about how much space browsers take while doing it, both in terms of disk space and memory. Finally there are some things that are traditionally harder to measure, such as responsiveness.

(more…)

Alex Pakhotin did some great work over the last couple weeks to get our update system working on Android, followed up by Aki Sasaki getting all the server side bits together. The result? You’ll now get prompted to update your Fennec nightly builds on Android.

Oh hey! Fennec’s trying to tell me something.	Oh cool! There’s an update available for Fennec!

↓

↓

↓

Oh wow these dialogs are ugly. But, they get the job done for now. In fact, new, mobile-friendly dialogs have already landed, but I won’t be able to see them until tomorrow’s update. Also, for the time being these updates are “complete” meaning they’re big. Soon we’ll have support for “partial” updates which are binary diffs between builds and will be much smaller.

Sometimes I have to use nightly builds to track down when regressions happen. There are two things that are annoying about that. First, I usually know I want a nightly build from a certain day, but I don’t know what hour that build was produced by the nightly builders, so I wind up scanning through a long list of folders like this. The second is that because of the way android installers are signed, I have to uninstall my private build, which blows away my profile. Matt Brubeck put instructions on how to sign the the unsigned builds with your own key on the Fennec project wiki page.

So I put together a little script that tries the possible nightly build URLs until it finds one, then resigns it and installs it. Hopefully you find it helpful.

http://www.lassey.us/getnightly.sh

It turns out you can take a screenshot from your android device without rooting it. Simply download the android SDK (http://developer.android.com/sdk/index.html) and extract it as instructed. In the tools folder of your SDK there is a utility program called ddms. Launch that, it should look something like this:

(Note: Mac users need to launch this with the X11 running)

Simply click on the device you want to take a screenshot from to select it. Then under the device menu, you’ll find “Screen capture”, which does what you’d expect it to do.

And… you’re done. Enjoy.