Thanks to the great work of Kim Moir we now have nightly builds of Firefox for Android x86. If you have one of these devices, such as the Motorola Razr I, ZTE Grand X or Intel Black Ray you can download a nightly from here.

Intel_Inside_Razr_iFirefox_Razr_I_2

There is plenty of work to go before we can roll support for x86 out to our release channel, such as being able to produce signed release builds, bringing up automated testing in our continuous integration system, performance testing and of course QA. All of which is underway already. Once the quality and testing are up to our usual standards you should be able to find Firefox in a Google Play store near you. I’ll be sure to blog about it when that happens.

As I write this I’m sitting on a Virgin flight to SFO from Boston. Strangely enough, exactly 5 years and a day ago I was also on a Virgin flight to SFO from London. Back then I was flying out to start my new job at Mozilla. Earlier that year I had started to get antsy in my previous job and when Doug T heard about it he asked if I’d be interested in coming to Mozilla. My first thought was “there’s no way I could hack it at Mozilla.” In the previous 2 years I had been working with Doug T on Minimo and was consistently impressed and humbled by by the abilities of everyone I had interacted with at Mozilla.

My second thought was that I really had no interest in working on Joey. About a year ago the MoCo had officially stopped working on Minimo, not believing it was worth investing limited time and energy into a mobile browser. But Schrep was pretty convincing in telling me that Mozilla had changed its mind and was now serious about investing in a mobile browser and building a team to do it.

So I flew out, interviewed, got the job and the rest is history. We’ve had 3 great 1.0-like Fennec releases since then (side note: the name Fennec came from a google search for “small fox”), plus one aborted release for Windows Mobile which got to Alpha before Microsoft pulled the plug on Windows Mobile.

First we released a single process XUL-based product in January 2010. Responsiveness was an one of the biggest complaints about that release, so we largely rewrote the product to be multiprocess, but still XUL based. We released that as Firefox 4.0 for Android and Maemo May 2011. That release also got us on the same shipping schedule as desktop Firefox. We stayed on the rapid release schedule for 6 more releases, but eventually it became obvious that our start up time and memory footprint (which was causing Android to kill us in the background) were preventing us from being a competitive product on Android. So we re-wrote the product once more. This time we went with a native UI, which could come up fast so the user can start interacting with the product right away. We also switched back from the multiprocess architecture to a single process architecture, but retained our responsiveness by making that one process more multithreaded.

Looking back at the last 5 years is pretty satisfying at this point. Its been a winding road, but we’ve wound up in a great place. Firefox for Android is a product that I feel great telling my friends about. Even still there are plenty of exciting things coming down the road and some great challenges we need to wrap our heads around.

The mobile team is coming to Boston the 3rd week of August along with some of our friends from graphics, layout, sync, automation and QA for a work week. As part of the week we’re holding a hack day focusing on mobile games and mobile add-ons on Thursday August 16th on the 7th floor of 281 Summer st. in Boston (aka Space with a Soul).

The day will start out with a couple quick talks to help people get started with technologies they might not be familiar with. Mark Finkle will walk everyone through how to create restartless (aka bootstrapped) add-ons in the new native front end of of Firefox for Android. Vladimir Vukicevic will show off some of Firefox for Android’s capabilities as a gaming platform. Finally Pascal Rettig will talk about tips and tricks for HTML game development.

Following the presentations will be pitch time. If you have an idea, you get 1 minute to pitch it to the group and get people excited. We’ll then break for lunch and let people form teams around those ideas. The rest of the day we’ll spend cranking out code. Finally, to wrap up, the teams will have an opportunity to show off what they’ve created at the end of the day.

If you can join us please register at http://mozhackbos.eventbrite.com and start brewing up some ideas.

We launched pretty cool product about a month ago. It got lots of really great coverage in the press. After spending 9 months rewriting Firefox for Android, we’re really happy with the results. But that mostly just establishes a baseline for us and onward we go. Firefox 15 has lots of great new features that I promise I’ll blog about real soon.

Right now we’re super excited to call attention to the fact that we are bringing support for ARMv6 to Firefox for Android. Specifically, we landed all of the patches needed for ARMv6 support during Firefox 16′s time on trunk. So as the Firefox 16 train rumbles along the tracks to the Aurora station, we now have Aurora nightly builds and an associated update channel to keep you on the latest and greatest. These are the obvious continuation of the ARMv6 trunk nightly builds that Armen blogged about.

Now you get to choose between staying on the bleeding edge and seeing the latest and greatest things on the Nightly channel, or a more stable experience on our Aurora channel. Either way, you’re helping us ship a great product for ARMv6 users.

What is ARMV6 you ask? Well, ARM is the CPU architecture that powers the vast majority of mobile devices. As with everything technology related, the ARM Architecture evolves and with each new version of ARM new features get added that allow developers to either do entirely new things or maybe just do old things faster.

Specifically, we choose to target ARMv7 originally to take advantage of the Thumb-2 instruction set that was introduced with that version of the architecture. The main benefit of the Thumb-2 instruction set is it produces smaller binaries. In fact the ARMv7 (using Thumb-2) version of libxul.so is 40% smaller than the ARMv6 version of libxul.so (23.8MB vs. 17MB). In addition, the smaller binary size results in a performance benefit since more of the library’s binary will be cached at any given time. it should be noted though that due to compression, the resulting ARMv6 apk  is only 2MB bigger than the ARMv7 apk.

When we made the decision to use Thumb-2 binary for Firefox, the Android Market only allowed you to ship one version of your app at a time. Since then the Android Market (eventually renamed Google Play) added support for shipping different APK’s to different devices. This opened the door to us being able to ship the smaller and faster binaries to devices that were compatible with it and at the same time address the other half of the market which is running on ARMv6 hardware.

So, if you’ve previously been unable to get Firefox from the Google Play Store, please go grab an Aurora build and give it a try. We’d love to hear your feedback, which you can provide by signing up for the ARMv6 Mobile Test Drivers mailing list, and you’ll be helping to bring Firefox to millions more users who have been left behind by modern browsers.

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)

 

As I tweeted last week, DynDNS killed my account again but this time I was in California for 2 weeks, leaving me without access to my home network. That was less than convenient. So, on my to-do list for when I got home was trying to figure out a more robust solution. Turns out its pretty simple to do with DreamHost’s APIs and a cron job. Here’s my script:

KEY="YOUR_DREAMHOST_API_KEY"
HOST="your_server.you.com"
current_dns=`curl "https://api.dreamhost.com/?key=$KEY&cmd=dns-list_records" 2>/dev/null | grep "$HOST" | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}'`
current=`curl "http://lassey.us/whatsmyip.php"`
if test $current = $current_dns; then
    echo "their equal"
else
    echo `curl "https://api.dreamhost.com/?key=$KEY&cmd=dns-remove_record&record=$HOST&type=A&value=$current_dns"`
    echo `curl "https://api.dreamhost.com/?key=$KEY&cmd=dns-add_record&record=$HOST&type=A&value=$current"`
fi


And the content of http://lassey.us/whatsmyip.php is:

<!--?php echo getenv("REMOTE_ADDR");  ?-->


Hopefully that helps out anyone else that’s facing the same frustration.

Next Page »