Attempting to run Fennec 53+ on a non-NEON device should fail gracefully.

There may be a more elegant way of handling this, but I just went with loading mozglue in BrowserApp.onCreate() to ensure we can check NEON compatibility there and handle it identically to any other unsupported system.

Can you do some autophone runs to see the startup impact of loading mozglue early?

Here's an autophone comparison with/without this patch: https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-inbound&originalRevision=6964fbecaacc&newProject=try&newRevision=198ee1f756c9fc1be9c1f4c52769dbdd34f763e1&framework=3&showOnlyImportant=0 It doesn't look to me like it makes any significant impact.

Comment on attachment 8844677 [details] [diff] [review] NEON non-compatibility kill-switch Review of attachment 8844677 [details] [diff] [review]: ----------------------------------------------------------------- Don't you want to remove the EOL check in BrowserApp? Also, I think we want to show a different message because the message shown here is "Sorry! ... Please download the correct version." [1] [1] http://searchfox.org/mozilla-central/rev/7cb75d87753de9103253e34bc85592e26378f506/mobile/android/base/locales/en-US/android_strings.dtd#821

Unfortunately, I think it's too late to add strings to 53 at this point, and it doesn't look like we have any existing strings that would be a better fit. I got rid of the EOL check, carrying over the r+.

Pushed by droeh@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/0cbf58746cae Check NEON compatibility in BrowserApp/GeckoApp.onCreate() and fail with an appropriate error message if necessary. r=jchen

I'm suspecting this is causing some android x86 mochitests of crashing like https://treeherder.mozilla.org/logviewer.html#?job_id=83148187&repo=mozilla-inbound Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/ce8ddd8bb7df5f052c3366a1a6260a7dce9be9dc to see if it fixes things.

This should be fixed by the updated patch in bug 1305815; pending good results from a try run I'll push this again.

Looks good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d5f4ac5b9243a678f544354354988aa4dd06c3d7

Pushed by droeh@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/872bb08cf17e Check NEON compatibility in BrowserApp/GeckoApp.onCreate() and fail with an appropriate error message if necessary. r=jchen

Comment on attachment 8845957 [details] [diff] [review] NEON non-compatibility kill-switch v1.1 Approval Request Comment [Feature/Bug causing the regression]: 1289569 [User impact if declined]: We are dropping support for non-NEON devices in 53; this will fail gracefully with an invalid build message rather than crashing. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: Not very. [Why is the change risky/not risky?]: Should only affect non-NEON devices, which otherwise will crash on launch for these versions. [String changes made/needed]: None

Comment on attachment 8845957 [details] [diff] [review] NEON non-compatibility kill-switch v1.1 We plan to drop support for non-NEON devices in 53. Aurora54+ & Beta53+.

Unfortunately on SOFTVISION side we do not have such device (it either doesn't work anymore or it is blocked on an older version of OS that we already blocked 2.x or 3.x) Kevin? Any chance here?

After installing the current nightly on a Galaxy Tab 2 launching Firefox shows the message "Sorry! This version won't work on your device (armeabi-v7a, 15). Please download the correct version. That seems wrong given that there is no correct version.

(In reply to Kevin Brosnan [:kbrosnan] from comment #17) > After installing the current nightly on a Galaxy Tab 2 launching Firefox > shows the message "Sorry! This version won't work on your device > (armeabi-v7a, 15). Please download the correct version. > > That seems wrong given that there is no correct version. Jim brought this up in comment 4, but as far as I understand it is far too late to try and add a new string to 53 for this. If we want to add a new string for future versions, let me know what I need to do.