We currently do two split builds: API 9-10 and API 11+. I propose one of two things in the 40-ish timeframe (when's our next ESR?): * Dropping Honeycomb altogether, API 11-13. * Dropping Honeycomb 11-12. API 13 fixes a lot of stuff that is broken in earlier Honeycomb, so this is still a win. Android 3.2 (API 13) makes up 1.12% of our install base. Earlier Honeycomb versions are less than 0.5%. Presumably these sets of users aren't very active, so downweight those numbers accordingly. Developers routinely don't test on Honeycomb. We do cause bugs as a result (Bug 1154836 being the most recent in my inbox, but I see also Bug 987795, Bug 1055556, … — even ignoring the bugs that we've already WONTFIXed). We have a hard time fixing bugs on Honeycomb because most devs can't test there. Eliminating support for these API versions leads to simpler code, smaller APKs, less developer time spent fixing bugs that affect a tiny proportion of our user base, and faster delivery of working features. The only reasons IMO to keep this support around are: * To avoid discontinuity in supported API ranges, which might confuse contributors. * If a partner demands that we offer support for Honeycomb.

How would the mechanics of this work in the play store?

I would prefer a clean drop. Using ESR was a hack for 2.2 to drop support sooner than the population decline allowed. If it is not worth time to spend developer time on it it is not worth the time to build, qualify and release it.

(In reply to Brad Lassey [:blassey] (use needinfo?) PTO April 11-19 from comment #1) > How would the mechanics of this work in the play store? IIRC: existing users stick with the version they have, and Play doesn't offer them updates. New users can't install ("not available for your device").

(In reply to Richard Newman [:rnewman] from comment #3) > (In reply to Brad Lassey [:blassey] (use needinfo?) PTO April 11-19 from > comment #1) > > How would the mechanics of this work in the play store? > > IIRC: existing users stick with the version they have, and Play doesn't > offer them updates. New users can't install ("not available for your > device"). The play store has come a long way since 2011, but when we tried to do this during the Fennec native rewrite, it didn't work.

Should be easy to test this, given a device at API 'N': 1. Upload a Fennec that supports N-1 and up. 2. Install it. 3. Upload a Fennec with a newer version code that supports N+1 and up. 4. Verify that the device still has the older version installed, and doesn't see any updates in Play. I'll do this at some point unless someone beats me to it.

mfinkle opines that it's killing time. Honeycomb percentage of MAUs is now negligible.

This patch bumps the minimum SDK range in our mozconfigs from 11 to 14. Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1277181d79ca Remaining work: * Rename the build to API 14+. * Test. * Explore Play Store interaction, decide whether the outcome is acceptable. * File bugs to remove Honeycomb compat code (or replace it with scary asserts to keep switch statements looking sane) once this lands. * Write blog posts, release notes for Play, etc.

This is also a great opportunity to tackle Bug 1062537, and that's a dependency for removing any Honeycomb compat code. One year ago, API <15 was 0.056% of the x86 user base. I doubt that's changed much.

I'm glad we added this check!

Comment on attachment 8677513 [details] [diff] [review] Part 2: bump Android version code computation check. Review of attachment 8677513 [details] [diff] [review]: ----------------------------------------------------------------- ::: python/mozbuild/mozbuild/android_version_code.py @@ +17,5 @@ > base = int(str(buildid)[:10]) > # None is interpreted as arm. > if not cpu_arch or cpu_arch in ['armeabi', 'armeabi-v7a']: > # Increment by MIN_SDK_VERSION -- this adds 9 to every build ID as a > + # minimum. Our split APK starts at 14. `android_version_code_v0` is legacy and no longer used. We should not update this code at all. @@ +59,3 @@ > otherwise, which means the build targets Android API 9-10 (Gingerbread). > + > + Fennec no longer supports below Android API 9, or -- after Bug 1155801 -- nit: "supports below Android" is awkward. This write-up of what we support is also misleading. It's not true that we don't support API 11-13, since an Android 11-13 user can download the 9+ split. Right? Perhaps: ``` The mainline Fennec APK split supports Android 14+. There is also an split that supports 9+. ``` @@ +108,5 @@ > if not cpu_arch or cpu_arch in ['armeabi', 'armeabi-v7a']: > # 0 is interpreted as SDK 9. > if not min_sdk or min_sdk == 9: > pass > + # This used to compare to 11. The 14+ APK directly supersedes 11+, so Hmm, okay. Can we bump our tests as well to demonstrate this?

Comment on attachment 8677452 [details] [diff] [review] Part 1: drop Honeycomb support for ARM devices. v1 Let's consider a few things before landing this: 1. We should get the APK naming fixed up 2. Product needs to a+ and get messaging started 3. What followups do we need to remove any Honeycomb specific code and resources?

Comment on attachment 8677452 [details] [diff] [review] Part 1: drop Honeycomb support for ARM devices. v1 Review of attachment 8677452 [details] [diff] [review]: ----------------------------------------------------------------- The patch is fine for what it does. Looking in DXR for MOZ_ANDROID_MIN_SDK_VERSION suggests a few other places we need to consider: * https://dxr.mozilla.org/mozilla-central/source/mobile/android/b2gdroid/confvars.sh#25 b2gdroid is supporting 11+ only, so this has a more significant impact on them. * all the build.gradle's hard code API 9, for irritating reasons. Bump them all, please. * I seem some random uses in automation, etc. Worth bumping or delegating. (Here's another reason to extract a GeckoView package: we can make GV support a wide API range, and then the App on top support a narrower API range. Not sure how valuable this is, with media codec, etc.)

Release Note Request (optional, but appreciated) [Why is this notable]: Drop of a supported arch [Suggested wording]: Honeycomb unsupported (need better wording) [Links (documentation, blog post, etc)]: [Tracking Requested - why for this release]: We probably want to track that and relnotes it. Not sure if we are planning to do that in 44.

(In reply to Mark Finkle (:mfinkle) from comment #12) > Comment on attachment 8677452 [details] [diff] [review] > Part 1: drop Honeycomb support for ARM devices. v1 > > Let's consider a few things before landing this: > 1. We should get the APK naming fixed up jlund: how much pain is there changing the name "android-api-11" to "android-api-14"?

(In reply to Nick Alexander :nalexander from comment #13) > b2gdroid is supporting 11+ only, so this has a more significant impact on > them. I think there's a strong case to push that to 14+. It'll disappoint all four humans in the world who want to run b2gdroid on a Honeycomb tablet that don't want to upgrade to ICS or later… but screw those people.

(In reply to Nick Alexander :nalexander from comment #11) > This write-up of what we support is also misleading. It's not true that we > don't support API 11-13, since an Android 11-13 user can download the 9+ > split. Right? It's worth talking about this a little. There are two stages we can see in this process. The first is that we simply change the minSdkVersion in one of our splits, and don't change any code. Honeycomb users can conceivably run the Gingerbread build; they'll get a phone UI rather than a tablet UI, and perhaps some bugs (e.g., wrong libomxplugin) or UI oddities. I'm hesitant to call that "support" (we won't fix reported Honeycomb bugs, right?) but that's semantics. At this point it's still possible to produce a single APK that works correctly on Android 9-23; we just wouldn't do so in automation. (We won't be testing on Honeycomb, which is half of the point of doing this work, and it'll start to get buggy, but that'll take time.) The second stage is that we actively remove code that specifically supports Honeycomb -- workarounds for platform bugs, media code, the use of compat libraries, Honeycomb branches in switch statements. At that point we will not run correctly on 11-13: those workarounds exist for a reason. It'll be possible to produce a build that will *install* on Honeycomb, but it's likely to crash or be buggy -- hitting tablet code paths that no longer contain Honeycomb workarounds, for example. This will be the first time that we will only support discontinuous API ranges.

(In reply to Richard Newman [:rnewman] from comment #17) > At that point we will not run correctly on 11-13: those workarounds exist > for a reason. And as I implied in Comment 8, after this point we can't support 11-13 on the single x86 APK, either. Because there are almost no x86 Gingerbread devices, and hardly any ICS or before, we should bump that straight to 15+.

(In reply to Nick Alexander :nalexander from comment #13) > Looking in DXR for MOZ_ANDROID_MIN_SDK_VERSION suggests a few other places > we need to consider: I addressed most of these in the try push I just submitted, parts 1-5. Take a look if you get the chance.

(In reply to Mark Finkle (:mfinkle) from comment #12) > 1. We should get the APK naming fixed up Nick ni'd jlund. > 2. Product needs to a+ and get messaging started ni Barbara. > 3. What followups do we need to remove any Honeycomb specific code and > resources? I filed Bug 1217675 to track that work. I expect it'll turn out like Bug 1017242.

https://hg.mozilla.org/try/rev/3ddced85deac > Part 3: bump all build.gradle files to minSdkVersion 14. But then I can't deploy builds to Gingerbread devices anymore?

Hi friends, can somebody please confirm that "drop" means in this context a) not supporting Honeycomb moving forward by not fixing any bug related to it b) Fennec won't work anymore on Honeycomb c) when should we schedule this for?

(In reply to Barbara Bermes [:barbara] from comment #23) > a) not supporting Honeycomb moving forward by not fixing any bug related to it Correct. > b) Fennec won't work anymore on Honeycomb Correct, with the exception of the possibility Nick mentioned of users running the Gingerbread phone version on their Honeycomb tablet. This bug in particular is about dropping it from our builds, so we'd ship [9-10] and [14+]. We don't know yet whether existing Google Play users will simply be stranded on their last installed Firefox version from Play (no new APKs will match their system), whether they'll be shifted to the newer Gingerbread APK, or whether something else will happen. > c) when should we schedule this for? In Comment 2, Kevin suggests not bothering with a final ESR, and I agree. I'd suggest making sure this lands before ESR 45 is cut, so we don't have to pretend to support Honeycomb until the end of 2016.

(In reply to Sebastian Kaspari (:sebastian) from comment #22) > https://hg.mozilla.org/try/rev/3ddced85deac > > Part 3: bump all build.gradle files to minSdkVersion 14. > > But then I can't deploy builds to Gingerbread devices anymore? Correct, at least not right away. Is this a use case for you? The only reason we hard-code this into build.gradle (rather than using MOZ_ANDROID_MIN_SDK_VERSION) is that the IntelliJ/Android/Gradle integration has (had?) this unbelievably hacky build.gradle parser that extracts the minSdkVersion without using Groovy. (Bonkers, I know.) We could investigate further to figure out if that's still the case; and we could probably arrange to dynamically override the minSdkVersion (using project.afterEvaluate) to lie to the IDE and set it at build time. That'd let you deploy 9-10. Bottom line: I want to move builds to Gradle, which means we need to be able to build our APK splits, end of story. We'll find a way to make it happen.

(In reply to Nick Alexander :nalexander from comment #25) > (In reply to Sebastian Kaspari (:sebastian) from comment #22) > > https://hg.mozilla.org/try/rev/3ddced85deac > > > Part 3: bump all build.gradle files to minSdkVersion 14. > > > > But then I can't deploy builds to Gingerbread devices anymore? > > Correct, at least not right away. Is this a use case for you? Sure, that's how I debug and test things on Gingerbread devices.

(In reply to Nick Alexander :nalexander from comment #15) > (In reply to Mark Finkle (:mfinkle) from comment #12) > > Comment on attachment 8677452 [details] [diff] [review] > > Part 1: drop Honeycomb support for ARM devices. v1 > > > > Let's consider a few things before landing this: > > 1. We should get the APK naming fixed up > > jlund: how much pain is there changing the name "android-api-11" to > "android-api-14"? not much. anywhere its referenced, it should be used mostly for identifiers/naming so a few s/11/14/g in various repos and we should be good. bonus: it's slightly less work than changing api-9 because api-9 is the funny one in balrog (update server)

I went through the output of 'ack' and hit what I thought made sense.

Updated patch for part 1.

Updated patch: adjusted test, undid change to v0.

> > b) Fennec won't work anymore on Honeycomb > > Correct, with the exception of the possibility Nick mentioned of users > running the Gingerbread phone version on their Honeycomb tablet. > > This bug in particular is about dropping it from our builds, so we'd ship > [9-10] and [14+]. > > We don't know yet whether existing Google Play users will simply be stranded > on their last installed Firefox version from Play (no new APKs will match > their system), whether they'll be shifted to the newer Gingerbread APK, or > whether something else will happen. Thanks, is there any way this can be more predicable so we know what to tell users, i.e. prepare appropriate SUMO etc?

> > b) Fennec won't work anymore on Honeycomb > > Correct, with the exception of the possibility Nick mentioned of users > running the Gingerbread phone version on their Honeycomb tablet. > > This bug in particular is about dropping it from our builds, so we'd ship > [9-10] and [14+]. > > We don't know yet whether existing Google Play users will simply be stranded > on their last installed Firefox version from Play (no new APKs will match > their system), whether they'll be shifted to the newer Gingerbread APK, or > whether something else will happen. Thanks, is there any way this can be more predicable so we know what to tell users, i.e. prepare appropriate SUMO etc?

I left a needinfo for Sylvestre last week, which mid-aired with Fabrice's r+. Re-posting, which should answer your question, Barbara! -- Sylvestre, finding out what happens here for Play users requires uploading some builds. One way to do this is to upload a new app in both configurations. Another is to use the org.mozilla.fennec_aurora app we already have in the Console. Can we do the latter, and can you help? The two kinds of users we care about: * Honeycomb users who already have the 11+ APK installed. * Honeycomb users who don't have anything installed. I'm interested to know what Play offers each of those when an update is available, when the new update is built with the same patches in that Try build.

Happy to help. using org.mozilla.fennec_aurora sounds good!

Tracking as it is an important step.

Landed Part 4 as Bug 1218410. https://hg.mozilla.org/integration/fx-team/rev/07625f7a06d9

I filed Bug 1219094 to track renaming the job, and added some notes there about possible updater work.

Richard, do any of these patches need to be uplifted to Aurora44? I noticed that the patches are r+d, but were not checked into Nightly. Is that expected?

(In reply to Ritu Kothari (:ritu) from comment #40) > Richard, do any of these patches need to be uplifted to Aurora44? I noticed > that the patches are r+d, but were not checked into Nightly. Is that > expected? We're targeting Fx45 for this, not 44. Right now we're blocked on testing this in bug 1223348. Richard, are these patches upliftable? Or do we need to make sure we land these before the merge?

They're all upliftable and low-risk until at least late Aurora, perhaps even Beta. I don't want to land them in Nightly at all until we know that we can commit to this course of action on the Play Store in Beta and Release. If we can't, then we're stuck supporting Honeycomb until we abandon Gingerbread. I think that's unlikely, but we should know what we're getting ourselves into before we cut off our ability to test Honeycomb on Nightly and Aurora.

(In reply to :Margaret Leibovic from comment #41) > (In reply to Ritu Kothari (:ritu) from comment #40) > > Richard, do any of these patches need to be uplifted to Aurora44? I noticed > > that the patches are r+d, but were not checked into Nightly. Is that > > expected? > > We're targeting Fx45 for this, not 44. Right now we're blocked on testing > this in bug 1223348. > > Richard, are these patches upliftable? Or do we need to make sure we land > these before the merge? Thanks Margaret and Richard. That makes sense, will wontfix this for FF44.

Added to the release notes even if it didn't land yet (to be clear that we are going to remove it). I reused the same wording as 2.2 "Android Honeycomb (version 3) no longer supported"

Just to clarify, we have an EOL notification in Fx45, so that means we would want to land these patches in Fx46, right? Otherwise users wouldn't get an update to 45 to see that message?

Comment on attachment 8701299 [details] [diff] [review] Part 3: bump all build.gradle files to minSdkVersion 14. v2 Unbitrotting some patches, and removing part 4 which has already landed.

(In reply to :Margaret Leibovic from comment #45) > Just to clarify, we have an EOL notification in Fx45, so that means we would > want to land these patches in Fx46, right? Otherwise users wouldn't get an > update to 45 to see that message? That's an excellent point. If 45 is as soon as we can get the EOL notification out, then yes, 45.0.0.0.1 or later to remove support.

How does this affect the API 9 Version for Android 2.3?

(In reply to Jan Manthay from comment #50) > How does this affect the API 9 Version for Android 2.3? It doesn't. We currently have these splits: [9-10] [11+] This bug will change that to: [9-10] [14+] Eventually we'll eliminate Gingerbread support too, but Gingerbread has 20x the number of installed devices as Honeycomb, so the cost-benefit slider is in a different place.

Chenxia verified the update experience in bug 1223348, so should we go ahead and land these patches for 46?

Let's do it! Chenxia, if you have these in your queue, would you do the honors?

(In reply to Richard Newman [:rnewman] from comment #53) > Let's do it! Chenxia, if you have these in your queue, would you do the > honors? Chenxia is PTO until Jan 11. Do you want to just land these?

https://hg.mozilla.org/integration/fx-team/rev/4789d3f0bc0786017993b29d1308168b808425e6 Bug 1155801 - Part 1: drop Honeycomb support for ARM devices from Fennec mozconfigs. r=nalexander,mfinkle https://hg.mozilla.org/integration/fx-team/rev/991a5607ee54c41c3dfcf4ca2f63ec58512ebed8 Bug 1155801 - Part 2: bump Android version code computation check. r=nalexander https://hg.mozilla.org/integration/fx-team/rev/995c8eadd377d0a2538cb4260f88534b8f3e03c1 Bug 1155801 - Part 3: bump all build.gradle files to minSdkVersion 14. https://hg.mozilla.org/integration/fx-team/rev/06a75f114c316479598d2d147a772b7161abfe57 Bug 1155801 - Part 4: miscellaneous SDK_INT bumps.

(In reply to :Margaret Leibovic from comment #54) > Chenxia is PTO until Jan 11. Do you want to just land these? Done. Fingers crossed! jlund, could you file follow-ups for wherever we need to s/11/14?

> jlund, could you file follow-ups for wherever we need to s/11/14? Oh, and we also need to make sure that we stop serving new Nightly updates to existing users on API 11-13.

https://hg.mozilla.org/integration/fx-team/rev/5a34e31b0c2793667b5fe47edcdce0e4adca1709 Backed out changeset 06a75f114c31 (bug 1155801) https://hg.mozilla.org/integration/fx-team/rev/ddfa8329b57b6a31c0e9994ec9d8769061e00cdb Backed out changeset 995c8eadd377 (bug 1155801) https://hg.mozilla.org/integration/fx-team/rev/2819a299e08491bc9c76409afd0b927bf5f06fd0 Backed out changeset 991a5607ee54 (bug 1155801) https://hg.mozilla.org/integration/fx-team/rev/fe35ded611806957a4112511877e16bd72ccf795 Backed out changeset 4789d3f0bc07 (bug 1155801) on suspicion of causing b2gdroid bustage

Backed out for busting b2gdroid like this: https://treeherder.mozilla.org/logviewer.html#?job_id=6383534&repo=fx-team

This surprises me, given Bug 1218410.

https://hg.mozilla.org/integration/fx-team/rev/7bdaa6c5cd36e02adc74c2c68904acfa9adafbc0 Bug 1155801 - Part 1: drop Honeycomb support for ARM devices from Fennec mozconfigs. r=nalexander,mfinkle https://hg.mozilla.org/integration/fx-team/rev/e98295cfd4e22b61c4c20028e859f0493949ee91 Bug 1155801 - Part 2: bump Android version code computation check. r=nalexander https://hg.mozilla.org/integration/fx-team/rev/3af37c2f72f3501eb6a0956c959184dfc528fd88 Bug 1155801 - Part 3: bump all build.gradle files to minSdkVersion 14. https://hg.mozilla.org/integration/fx-team/rev/ee2069e90c51ff94d75004dd1c729e852c1b6bbe Bug 1155801 - Part 4: miscellaneous SDK_INT bumps. https://hg.mozilla.org/integration/fx-team/rev/fb6f3f5eedff7272038783b8069a0066bd14fd2e Bug 1155801 - Follow-up: fix b2gdroid builds for Android API 14.

https://hg.mozilla.org/mozilla-central/rev/7bdaa6c5cd36 https://hg.mozilla.org/mozilla-central/rev/e98295cfd4e2 https://hg.mozilla.org/mozilla-central/rev/3af37c2f72f3 https://hg.mozilla.org/mozilla-central/rev/ee2069e90c51 https://hg.mozilla.org/mozilla-central/rev/fb6f3f5eedff

(In reply to Richard Newman [:rnewman] from comment #58) > > jlund, could you file follow-ups for wherever we need to s/11/14? > > Oh, and we also need to make sure that we stop serving new Nightly updates > to existing users on API 11-13. tracking: "Bug 1219094 - releng work for dropping honeycomb support" will start that work once I receive the 'go'

API 14 has ~0 users, so let's just drop 14, too. I'll land a few little follow-ups.

Also noting this for 46.