Closed Bug 697205 Opened 10 years ago Closed 10 years ago

Get ARMv6 builds working again


(Firefox for Android Graveyard :: General, defect, P2)




Tracking Status
fennec 11+ ---


(Reporter: ted, Assigned: ted)



(Keywords: meta, Whiteboard: General feedback about the build can be left at

ARMv6 is some huge percentage of Android devices, something like 62%. By not supporting it our market is immediately cut by over a third. We should try to get these builds working again.

bug 696291 has a patch that should fix some JIT issues on ARMv6.
Keywords: meta
Alias: armv6
Depends on: 697709
Priority: -- → P2
Is this in any way tied to android sdk versions?
Depends on: 701708
Sorry for the lack of updates, glandium and I spent a combined week and a half tracking down bug 701708.
tracking-fennec: --- → 11+
Any update? Is bug 701708 the only thing blocking armv6 support?
I've got a local workaround for bug 701708, we'd just need to fix it on the build machines. I started looking at this again the other day, and we're still crashing in the linker (even with the new linker code). glandium remote-debugged it with me for a bit, and we figured out where it's failing, we just didn't figure out why it isn't working.
No longer blocks: 691281
Depends on: 723939
We tracked down the last remaining startup crash, it's bug 723939. With a fix for that we should be able to get builds going again. There may be other crashes (particularly in the JIT), but it'll be easier to find them with users using the builds again.
Blocks: 723946
With a local fix for bug 723939 and a workaround for bug 725284, I was able to get builds that start and mostly work on an ARMv6 phone:!/TedMielczarek/status/167248084613603329
FWIW, Ted's build SIGILLs on my samsung galaxy i7500 running gaosp. A custom build without a rebuilt stlport SIGFAULTs.
Can we assign this to a new dev? Ted is out till march 7th it seems
I think all the blockers here are on the Release Engineering side. I'm fairly confident we fixed all the actual blocking code bugs.
Depends on: 733773
Rebuilding stlport as arm and building with:
  ac_add_options --with-thumb=no
  ac_add_options --with-arch=armv6
  ac_add_options --with-fpu=toolchain-default
  ac_add_options --with-float-abi=toolchain-default

got me further. Bug 733773 will make this easier.
The resulting build doesn't crash in libxul anymore, but crashes, still. Logcat looks like this:
I/GeckoApp( 1561): Got message: Doorhanger:Add
I/GeckoApp( 1561): DoorHanger received for tab 1, msg:Help improve Fennec by sending anonymous usage information to Mozilla?
I/GeckoApp( 1561): Got message: Gecko:Ready
I/GeckoDoorHangerPopup( 1561): Adding a DoorHanger to Tab: 1
D/dalvikvm(  198): GC_EXPLICIT freed 341K, 50% free 4486K/8967K, external 2085K/2241K, paused 457ms
I/GeckoSoftwareLayerClient( 1561): Screen-size changed to (320,480)
I/GeckoSoftwareLayerClient( 1561): Showing checks: true
I/AndroidGraphicBuffer( 1561): disallowing board: I7500
I/GeckoSoftwareLayerClient( 1561): Creating MultiTileLayer
I/GeckoSoftwareLayerClient( 1561): Screen-size changed to (320,480)
I/Gecko   ( 1561): nsWindow::GetLayerManager
I/Gecko   ( 1561):  -- creating basic, not accelerated
E/InputDispatcher(  198): channel '4075ae68 org.mozilla.fennec_mh/org.mozilla.fennec_mh.App (server)' ~ Consumer closed input channel or an error occurred.  events=0x8
E/InputDispatcher(  198): channel '4075ae68 org.mozilla.fennec_mh/org.mozilla.fennec_mh.App (server)' ~ Channel is unrecoverably broken and will be disposed!
I/ActivityManager(  198): Process org.mozilla.fennec_mh (pid 1561) has died.
I/WindowManager(  198): WIN DEATH: Window{40784ce8 SurfaceView paused=false}
D/gralloc (  198): freeing GPU buffer at 0
D/gralloc (  198): freeing GPU buffer at 266240
I/WindowManager(  198): WIN DEATH: Window{4075ae68 org.mozilla.fennec_mh/org.mozilla.fennec_mh.App paused=false}
Depends on: 734050
That same build works fine on my device, so it seems to be something device-specific.
Mike, can I try the build in my Android 2.2 phone where newer builds where not supported? Would there be some risk?
Mike, I am going to try it my ViewPad7 and I will post results here, where can I download the source code?
The source code is mozilla-central + a few patches that are in the dependent bugs.
Thanks Mike, I am actually testing your build and it's working. Not crashing, it's fast and has some glitches by the way. To contribute what can I do? Posting here the bugs (with screenshots) or opening a new Bug-Ticket?
Works on Galaxy Next, but has worse performance than the stock browser. It uses 3x RAM, is slower while scrolling and zooming and, strangely, is a lot slower in loading pages. Probably performance should be improved before publishing on the market, however I've been waiting for it for many months :).
I tried it on my Samsung Galaxy Gio with CyanogenMod 7.2 (2.3.7) and it works quite flawless.

Scrolling is jumpy at time but overall this Fennec build is stable and fast.

Good job, guys!
We appreciate the testing, and obviously there will need to be more work done before release. The focus of this bug is simply to fix the issues that were preventing us from making builds that would actually run. Once all those bugs are fixed, we can get bug 723946 fixed to get nightly builds produced again, which will be much more useful for testing.
It's working ok in a stock Galaxy Ace with Android 2.3.4. Great job!!
Tried on Galaxy 5 GT-I5500. It works but it's a bit "unresponsive" in the sense that I'm having trouble clicking on Google search results and that when I start to load a (large) page and hit the back button on my phone, it sort of sits there and thinks about it for about 10 seconds before it does anything.
Once loaded, scrolling is fine, haven't figured how to zoom as it doesn't like the zoom button of the phone.
Looks that is missing a double tap to zoom function like others apps. I only get to zoom using multitouch gestures.
I think, as Ted said, that we should wait the nightly builds and then opening a new ticket describing the various issues as for now I see that some issues described from Jorge and others are not present in my device but if all we start to talk about bugs and issues we are just going to hijack the thread... and hijacking is not good especially by us that we were just readying this thread and waiting for a binary to be distributed.

Now, I think it's just time to say thanks and waiting the nightly builds.
This build works for me on:
* Samsung Galaxy Ace (posting this comment from it!)
* Samsung Galaxy III (5700)

I can use Firefox on my phone, awesome. Thanks, Ted!
(In reply to Mike Hommey [:glandium] from comment #12)
> The build in question:

Mike - Would it be risky to run this build in my Android 2.2 phone where newer builds where not supported?
I'd appreciate your relpy as soon as you can. Thanks!
(In reply to Gabriela from comment #25)
> Mike - Would it be risky to run this build in my Android 2.2 phone where
> newer builds where not supported?
> I'd appreciate your relpy as soon as you can. Thanks!

It's running on my Android 2.2/ZTE Blade & seems mostly stable. I'd expect it would be safe for you, although it might feel a bit slow if your phone is very low spec.
Here is a try build:

It's current mozilla-central (ead9016b4102) + patches from bug 716544, bug 734050 and bug 733773, and with "ac_add_options --with-arch=armv6" added to mozconfig, which is the only thing required with the three mentioned bugs fixed. It works just as well on my phone (that is, no libxul crash, but one related to IME)
(In reply to Matthew Babbs from comment #26)
> (In reply to Gabriela from comment #25)
> > Mike - Would it be risky to run this build in my Android 2.2 phone where
> > newer builds where not supported?
> > I'd appreciate your relpy as soon as you can. Thanks!
> It's running on my Android 2.2/ZTE Blade & seems mostly stable. I'd expect
> it would be safe for you, although it might feel a bit slow if your phone is
> very low spec.

Mike - Mine is a Galaxy S2 phone, so I suppose it won't feel slow. I´ll run it and I'll tell you how it works. Thanks!
Mike's build also works on HTC Wildfire S.
It's amazing how quick it starts, but then there's small lag before context menus work smoothly. After a short period of time, everything is normal for me. I didn't manage to crash it.
Mike's latest build (Nightly) does not have the double-tap to zoom feature, but his first build (Fennec) did. However, I think the latest build performs a bit better.

Only issues I can see on my device (LG Vortex, CyanogenMod 7.2.0 (748MHz OC)) are that scrolling can sometimes leave me with a white or checkered white/gray screen which will normalize itself after a second or two, and that refocusing after zooming takes a tad longer than I would hope it does.

It starts up very fast, no crashing either.
Folks, again, we appreciate the testing, but this is not the appropriate place to report issues with these builds, unless your issue is that it crashes on startup.
On my HTC Hero with CyanogenMod 7.1.0, I could install and run it, and setup Sync. But apparently Sync did not do anything. The "Settings" menu entry is greyed out. When I click "Browse all Nightly add-ons", the address bar changes and the loading symbol is animated, but nothing happens. When I enter a URL (in short form, e.g.,, the "->" button is not clickable. In other words: Fennec runs, but I cannot get it to do anything useful ...
Looks like we testers should move discussion of broader issues with these builds to another venue :) I've made a thread in - hope that's the right place.
(In reply to Mike Hommey [:glandium] from comment #27)
> Here is a try build:
> a3d9309084af/try-android/

It works decent on a china phone, B63M, with ARMv6 CPU. 
That is the app installs, starts quickly, I can browse sites, prefs seem to work, but one significant problem related to render. 

When I zoom in, I get instant bitmap zoom of the displayed page, then, after a huge lag (many seconds), it renders the page again, at the new zoom level. Scroll also suffers from huge lag, until that part of the page is rendered in the viewport. 
The lag depends on page complexity and zoom level. The larger the zoom level, the larger the lag. Same lag applies when rotating the display. 

Thank you for making it work on ARMv6.
Forgot to mention : ARMv6 650MHz, Android 2.3.4, 444MB RAM
(In reply to Andrei Boros from comment #36)
> Forgot to mention : ARMv6 650MHz, Android 2.3.4, 444MB RAM

works on galay ace. armv6 800mhz 278 mb ram. thanks a lot guys we should make it happen.
too much ram usage also. if its fixed its good to go on ace
Unless you are crashing please do not comment on this bug. Use the newsgroups Matthew created a thread at
Whiteboard: General feedback about the build can be left at
Nightly 14 again can't start after successfully installation on Arm6. Is this a back step after working nightly 13.
There is only one working armv6 build. We don't produce armv6 nightlies yet.
Well, well, well, thank god, someone figured it'll be long before everybody drops ArmV6. I do believe that 60% is a somewhat optimistic figure ;)

It's working(!!!!!) on ZTE Blade (with CM7)!! :D

-- Issues --

- Beyond what has already been reported, I'd like to confirm that webgl IS working.

I've just installed and headed to my website, checking for that precious feature.
- Yes, webgl is damn slow (1 or 2fps) but, anyway, it's only an adreno 200, no surprise. 

- It's crashing and you'll get crash reports related to some basic webpages (git cloned from and to, my project's site. I can't yet tell if the crashes are webgl related or something else is to blame. If my logcat can be of any help, let me know.

Keep up the good work, I'm relying on you for the mobile section of my project.
Works on LG E510 Hub. ARMv6 800 mhz, 512 mb RAM
No longer depends on: 701708
Nightly build 2012-03-09 on Samsung Galaxy Mini with Android 2.2.1 was reported unresponsive by Android and the whole phone froze after being locked. This was after installation. Next run did not have that problem.
Matti, as per comment 41, (we don't produce armv6 nightlies yet), could you please tell me where do you obtain the nightly builds from? I would really appreciate it!
Maybe it was not really a nightly build but it calls itself Nightly. I got it from some site I found on Google but I don't remember the address.

Incidentally, Android reported that the browser did not respond again after I tried to download an Android application. This time Andoid version was 2.3.4.
Matti, right. Thanks anyway!
All the dependent bugs are fixed, so I'm going to mark this fixed as well. It's now again possible to produce an ARMv6 build from mozilla-central without any additional patches simply by building --with-arch=armv6. bug 723946 tracks getting nightly builds running again.
Closed: 10 years ago
Resolution: --- → FIXED
Indeed, the build I downloaded myself, following instructions in the comments above, it installed itself, but with a nightsky icon and the name in the launcher is Nightly, not Firefox, not Fennec.
When will official build for arm6 lunch any idea. Our can you provide unofficial build as a gift from Mozilla.
bug 723946 tracks producing ARMv6 Nightly builds again. This bug is closed, so please leave it be now.
Duplicate of this bug: 755705
Alias: armv6
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.