1220720 - Message EOL plan to Honeycomb users

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[:Margaret Leibovic]

As discussed last week, we should find a way to tell Honeycomb users that we're dropping support for their platform. If we want to do this in the product, it will require landing strings, so we should think about this sooner rather than later.

Karen, do you have anything more to add?

Comment 1

[Richard Newman [:rnewman]]

Some of this is gated on figuring out exactly what happens to Play users; I'm looking for a volunteer to do that research, so I don't have to.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

For 2.2 we did not do anything in product. What sort of in product messaging is planned? Doing more than the blog/newsgroup posts? This population is smaller than the 2.2/ARMv6 population that we EOL'ed a year ago.

Play users that currently have Firefox for Android on Honeycomb they will continue to be able to use the last version that supports Honeycomb. Users that search for Firefox on Play using Honeycomb will get no results for Firefox. Users may still be able to download and install current versions of Firefox by using adb install firefox.apk or download and install from our servers.

Comment 3

[Michael Comella (:mcomella) [NI reported issues only; no longer employed by Mozilla]]

(In reply to Richard Newman [:rnewman] from comment #1)
> Some of this is gated on figuring out exactly what happens to Play users;
> I'm looking for a volunteer to do that research, so I don't have to.

Was ARMv6 on Play? Maybe this research was already done?

Kevin, do you know or know who would?

Comment 4

[Richard Newman [:rnewman]]

This situation differs from both 2.2 and ARMv6 in that our API9-10 APK technically supports Honeycomb -- minSdkVersion is a requirement, but maxSdkVersion is just a recommendation.

After EOL, ARMv6 users would stick with the last APK that supported ARMv6.

After EOL, Froyo users would stick with the last APK that supported API8.

Honeycomb users… do they get the last API11+ APK, the newer API9+ APK, or something else? And are things different for new users versus those who already have an 11+ APK installed? I can make guesses, but they're just speculation. And if things don't do what we'd like, we'll have to add messaging along the lines of Bug 1119915.


There's also a potential product question because we still support Gingerbread. Having a split set of supported versions might be confusing, and that might be worth landing a string to clarify.

Comment 5

[Karen Rudnitski [:kar]]

blog posts / newsgroup will only hit a small percentage of folks, therefore we discussed the idea of presenting a window to the user when they upgrade to the latest version to give them a link to SUMO (where we can provide more detailed information) and a notification saying that that will be their last product update. 

BTW, I'm working with the tableau team to create a view of Fx version by platform break-down. HC users seem to be fairly well retained, but I want to see how many of them upgrade. I'll have that info soon.

Margaret, I'll write up a bug about showing that panel and hang it off of here as well, which I think will be useful not only for this exercise, but others in the future as well. I think this provides the basis of a 'good practice' when EOL-ing platform support.

Comment 6

[Kevin Brosnan [Ex-Mozilla]]

Richard is correct here. We had 2.2 and ARMv6 support on Play and we did testing around that. There is a valid concern that Honeycomb users will end up with the Android 2.3 package. 

What is the user action here? They don't have any control over the Android support for the device or have ignored OEM Android upgrades for several years. Something in product is going to drive negative reviews, feedback and cost us goodwill. For Honeycomb this might not bee to bad but the next two EOLs 2.3 and 4.0 are a much larger set of users.

Comment 7

[Karen Rudnitski [:kar]]

The user action is information (btw, I've written this up https://mozilla.aha.io/features/FENN-366 as a way of providing information to the user). Not doing anything is worse, in my opinion. If we're able to actively inform users of what's going on, they then have the choice to use another browser that will have further security updates applied - that's the main concern here. 

Not everyone can afford new tablets ever year (or every two years), especially if it becomes the family's tablet. And given that HC users are those that are retained the most, I'd like to do our best at letting them know what's happening (instead of relying on them watching a passing reference in a blog post). 

I doubt this would generate bad press, and regardless we'd have reactive press statements at the ready as well.

Comment 8

[:Margaret Leibovic]

(In reply to Karen Rudnitski [:kar] from comment #7)
> The user action is information (btw, I've written this up
> https://mozilla.aha.io/features/FENN-366 as a way of providing information
> to the user). Not doing anything is worse, in my opinion. If we're able to
> actively inform users of what's going on, they then have the choice to use
> another browser that will have further security updates applied - that's the
> main concern here. 
> 
> Not everyone can afford new tablets ever year (or every two years),
> especially if it becomes the family's tablet. And given that HC users are
> those that are retained the most, I'd like to do our best at letting them
> know what's happening (instead of relying on them watching a passing
> reference in a blog post). 
> 
> I doubt this would generate bad press, and regardless we'd have reactive
> press statements at the ready as well.

I commented in that Aha! card, but I'll repeat myself here. Rather than building a new piece of UI to message to users, I think we should either open a webpage in a new tab, or create a system notification that links to a webpage.

With this approach we'll have more time/flexibility to nail down the messaging of that webpage, and the client side fix will look similar to what we do for our feedback solicitation prompt (except rather than check how many times the browser has been launched, we'll check if this is a version we're planning to EOL).

Comment 9

[Karen Rudnitski [:kar]]

I also replied in the card, but also to reiterate :)

I used the term 'display area' in a generic way so as not to prescribe a solution. Opening up a webpage is a fab idea, since if we ever needed to, we could modify that content as well on-the-fly. 

so I think this is a very fine approach!

Comment 10

[:Margaret Leibovic]

Barbara/Anthony, what do you think we should do here? I think a system notification that takes the user to a SUMO page about how we're ending support for their platform would be a fine solution here.

From a technical perspective, we'd need to add some code to create this notification. I think we could do something very similar to what we currently do for the data reporting notification:
http://hg.mozilla.org/mozilla-central/file/e2a910c048dc/mobile/android/base/BrowserApp.java#l1804

And then we'll just need a SUMO URL to point to.

I think a notification would be better than automatically opening a tab, since users might not notice that new tab, or it would be getting in the way if the main way they use the browser is to open external links.

Comment 11

[Barbara Bermes [:barbara] - NI please!]

I'm good with the sys notification. It's more prominent to the user, imo.

So should this bug be more generic and about making a system notification feature available that can also be leveraged for things like this: https://mozilla.aha.io/features/FENN-370?

Comment 12

[:Margaret Leibovic]

I just noticed that we're doing something very similar in bug 1220904. Nick or Vivek, would you be interested in picking up this bug?

Comment 13

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Margaret Leibovic from comment #12)
> I just noticed that we're doing something very similar in bug 1220904. Nick
> or Vivek, would you be interested in picking up this bug?

These two cases seem very similar so I think we should take the same "notification" approach here.

Do we know which URL this notification should lead to? 

I know in bug 1220904, that notification is supposed to persist (not dismiss-able) until they sign in. 

I worry about persisting this one though since it may not be an option for some people (to get off Honeycomb). Any thoughts on not having this be a persistent one?

Comment 14

[Nick Alexander :nalexander [he/him]]

I'm happy to help land this.  I see little advantage to having the work together, though: different requirements, different release life cycle (Bug 1220904 is temporary), this is permanent-ish.

Comment 15

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Nick Alexander :nalexander from comment #14)
> I'm happy to help land this.  I see little advantage to having the work
> together, though: different requirements, different release life cycle (Bug
> 1220904 is temporary), this is permanent-ish.

Exactly right. Let's just move forward with this bug on it's own.

These aren't the droids you're looking for, move along.

Comment 16

[Karen Rudnitski [:kar]]

Anthony / Margaret / Nick (whoever!) - here's a URL you can use that was created by Joni. This is the link to the sumo article that will get created: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/honeycomb

Comment 17

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Perfect, do we have copy for this notification?

Comment 18

[Karen Rudnitski [:kar]]

Nope! Should we pull in Matej?

Comment 19

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Matej, any thoughts on this? For context, we do something similar in bug 1220904.

What do you think of the following?

> +-----------------------------------------------+
> |                                               |
> |  +-+  Firefox no longer supported             |
> |  +-+  Tap here to learn more                  |
> |                                               |
> +-----------------------------------------------+

where the +-+ on the left there is the Firefox 1 tone icon.

Comment 20

[Matej Novak [:matej]]

(In reply to Anthony Lam (:antlam) from comment #19)
> Matej, any thoughts on this? For context, we do something similar in bug
> 1220904.
> 
> What do you think of the following?
> 
> > +-----------------------------------------------+
> > |                                               |
> > |  +-+  Firefox no longer supported             |
> > |  +-+  Tap here to learn more                  |
> > |                                               |
> > +-----------------------------------------------+

This makes it sound like Honeycomb has dropped support for Firefox, rather than the other way around. At the very least, I'd like to add "is," but I worry that it's misleading this way.

Unfortunately I'm not familiar enough with how this works, where users will see it or even what Honeycomb is to be able to offer an alternative.

Could I get a little more background info?

Comment 21

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Matej Novak [:matej] from comment #20)
> This makes it sound like Honeycomb has dropped support for Firefox, rather
> than the other way around. At the very least, I'd like to add "is," but I
> worry that it's misleading this way.
> 
> Unfortunately I'm not familiar enough with how this works, where users will
> see it or even what Honeycomb is to be able to offer an alternative.
> 
> Could I get a little more background info?

Certainly! 

This will be in a system notification (visually it's the same as they one that prompts you when you get a text message, receive a tab, etc).

Honeycomb is the operating system version's name and unfortunately there's nothing they can do. The only option is for users to update their OS (this is sometimes a notification already but I think it depends on the device).

How about...?

> +-----------------------------------------------+
> |                                               |
> |  +-+  Android 3.0 is no longer be supported   |
> |  +-+  Tap here to learn more                  |
> |                                               |
> +-----------------------------------------------+

Comment 22

[Matej Novak [:matej]]

Thanks for the added info.

Would it make sense to add "Firefox" to the message?

> +-----------------------------------------------+
> |                                               |
> |  +-+  Firefox no longer supports Android 3.0  |
> |  +-+  Tap to learn more                       |
> |                                               |
> +-----------------------------------------------+

I also wonder if Android users know which version they're on, but unfortunately removing the number makes this a lot longer:

> +--------------------------------------------------------+
> |                                                        |
> |  +-+  This version of Android is no longer supported   |
> |  +-+  Tap to learn more                                |
> |                                                        |
> +--------------------------------------------------------+

Either way, I think we can just say "Tap" instead of "Tap here."

Comment 23

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Matej Novak [:matej] from comment #22)
> Thanks for the added info.
> 
> Would it make sense to add "Firefox" to the message?
> 
> > +-----------------------------------------------+
> > |                                               |
> > |  +-+  Firefox no longer supports Android 3.0  |
> > |  +-+  Tap to learn more                       |
> > |                                               |
> > +-----------------------------------------------+

This works!

I think so. I thought removing it would save characters but perhaps we can see if this fits and where it truncates. 

> I also wonder if Android users know which version they're on, but
> unfortunately removing the number makes this a lot longer:
> 
> > +--------------------------------------------------------+
> > |                                                        |
> > |  +-+  This version of Android is no longer supported   |
> > |  +-+  Tap to learn more                                |
> > |                                                        |
> > +--------------------------------------------------------+

Yeah, that's definitely part of the issue here too.

> Either way, I think we can just say "Tap" instead of "Tap here."

Agree!

Vivek, could we see how this fairs on an actual device? a screenshot would be fine, I'm mostly concerned with where the message would (mostly) truncate.

> > +-----------------------------------------------+
> > |                                               |
> > |  +-+  Firefox no longer supports Android 3.0  |
> > |  +-+  Tap to learn more                       |
> > |                                               |
> > +-----------------------------------------------+

Comment 24

[Chenxia Liu [:liuche]]

Vivek, let me know if you're working on this bug! Otherwise, I'm working on some other system notifications stuff, and I'll pick this up.

Comment 25

[Vivek Balakrishnan[:vivek]]

Attachment: MozReview Request: Bug 1220720: Notify EOL on Honeycomb r?liuche

Bug 1220720: Notify EOL on Honeycomb r?liuche

Comment 26

[Chenxia Liu [:liuche]]

Btw, this should be for EOL Honeycomb, but not for Gingerbread. Talked to vivek over irc, but just leaving a comment as a note.

Comment 27

[Karen Rudnitski [:kar]]

Note - honeycomb includes versions 3.0 - 3.2, therefore the message isn't totally accurate. Do we have room to add 'Android 3.0 - 3.2'?

Comment 28

[Chenxia Liu [:liuche]]

Comment on attachment 8688705 [details]
MozReview Request: Bug 1220720: Notify EOL on Honeycomb r?liuche

https://reviewboard.mozilla.org/r/25381/#review23003

This is great :) I'll swap the boolean check in this to build it and see if it works, and I'll also flag people to follow up how long we want to show this, or when it should be dismissed. For now it makes sense to just autocancel though.

::: mobile/android/base/BrowserApp.java:751
(Diff revision 1)
> +            if (prefs.getBoolean(PREF_HONEYCOMB_EOL_NOTIFIED, false)) {

This will enter the branch if EOL_NOTIFIED is true - we want the opposite (the second argument is the default value, not the value to be compared).

::: mobile/android/base/BrowserApp.java:758
(Diff revision 1)
> +                Intent intent = new Intent(Intent.ACTION_VIEW);

Nit: this can be final

::: mobile/android/base/BrowserApp.java:950
(Diff revision 1)
> +        if (Versions.preICS) {

We don't need to hide the notification on onStop - let's just have it persist, the way an "update Nightly" notification does. Guest Mode is a little different, because it's specific to the browsing session and doesn't make sense if the browser isn't open, whereas an EOL notification is fine to have even if the browser isn't open.

setAutoCancel is enough, but I'll flag kar in the bug and ask.

::: mobile/android/base/BrowserApp.java:3552
(Diff revision 1)
> +            if(isViewAction) {

Actually, I don't think we even need this check - we should show the notification once, and as soon as it's shown, never show it again. After thinking about this a little more, let's not require that the user go to the SUMO page - they should be able to get as much information as they need from the notification.

::: mobile/android/base/locales/en-US/android_strings.dtd:755
(Diff revision 1)
> +<!-- LOCALIZATION NOTE (eol_notification_title):notification title text-->

We don't need the two subsequent localization notes because the strings are very standard. The first strung needs the localization note because we have non-standard substitutions.

::: mobile/android/base/locales/en-US/android_strings.dtd:756
(Diff revision 1)
> +<!ENTITY eol_notification_title "Firefox no longer supports Android 3.0">

Let's use the channel name &brandShortName; instead of Firefox.

Comment 29

[Chenxia Liu [:liuche]]

Karen, Anthony: I suggested to vivek that we want to make this a dismissable notification that only shows once - what do you think? The alternatives are 1) require user to click the notification (going to the SUMO article) before clearing it from the notifications tray, and 2) require user to click the notification, otherwise we will show it again.

Anthony, what do you think of the strings kar suggested in comment #27? Should we add the extra versions, delineate that it's Honeycomb, and/or emphasize that THIS 3.* Honeycomb that the user is running right now is being EOL (and it's not just some random notification for an unrelated version).

Comment 30

[Vivek Balakrishnan[:vivek]]

Comment on attachment 8688705 [details]
MozReview Request: Bug 1220720: Notify EOL on Honeycomb r?liuche

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/25381/diff/1-2/

Comment 31

[Chenxia Liu [:liuche]]

Adding a dependency on bug 1226009 - currently, Firefox doesn't even start on Honeycomb.

Comment 32

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Karen Rudnitski [:kar] from comment #27)
> Note - honeycomb includes versions 3.0 - 3.2, therefore the message isn't
> totally accurate. Do we have room to add 'Android 3.0 - 3.2'?

I'd just go with "Android 3"

Comment 33

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Mark Finkle (:mfinkle) from comment #32)
> (In reply to Karen Rudnitski [:kar] from comment #27)
> > Note - honeycomb includes versions 3.0 - 3.2, therefore the message isn't
> > totally accurate. Do we have room to add 'Android 3.0 - 3.2'?
> 
> I'd just go with "Android 3"

Also, the webpage can be more specific. Let's not overthink this too much.

Comment 34

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Chenxia Liu [:liuche] from comment #29)
> Karen, Anthony: I suggested to vivek that we want to make this a dismissable
> notification that only shows once - what do you think? The alternatives are
> 1) require user to click the notification (going to the SUMO article) before
> clearing it from the notifications tray, and 2) require user to click the
> notification, otherwise we will show it again.
 
I'd go with 1. So, it's not dismiss-able. But, once the user clicks it, it launches the link and dismisses.

That seems reasonable and I've seen other applications follow a similar pattern.

> Anthony, what do you think of the strings kar suggested in comment #27?
> Should we add the extra versions, delineate that it's Honeycomb, and/or
> emphasize that THIS 3.* Honeycomb that the user is running right now is
> being EOL (and it's not just some random notification for an unrelated
> version).

I'm not too worried about this level of specificity and I don't think we have room either :\

Thanks Vivek!

Comment 35

[Karen Rudnitski [:kar]]

I agree with Anthony on the approach and both Anthony and Mark for the version, although I'd likely state '3.x' instead of star, unless that's what was meant :)

Comment 36

[Chenxia Liu [:liuche]]

Sounds good to me!

This is currently blocked by bug 1226009, which I am investigating right now.

Comment 37

[Chenxia Liu [:liuche]]

Attachment: "3.0" messaging

Comment 38

[Chenxia Liu [:liuche]]

Attachment: "3.x" messaging

1. Here's the messaging for 3.0 vs 3.x. I personally feel like 3.x looks a little weird, so asking you for feedback.

2. If you kill Fennec, the messaging goes away and does not return, even if you didn't click on it/read it. It should at least show up as a notification so the user could see it, but they might not. (We can add a DeleteIntent and listen for a Broadcast and only not show the notification if the user closes the intent or clicks on it, but this is a little more work and if you don't care, then let's not do it.)

Comment 39

[Chenxia Liu [:liuche]]

Attachment: MozReview Request: Bug 1220720: Notify EOL on Honeycomb r?liuche

Bug 1220720: Notify EOL on Honeycomb r?liuche

Comment 40

[Chenxia Liu [:liuche]]

Attachment: MozReview Request: Bug 1220720 - fixes to be folded in.

Bug 1220720 - fixes to be folded in.

Comment 41

[Chenxia Liu [:liuche]]

Comment on attachment 8691102 [details]
MozReview Request: Bug 1220720: Notify EOL on Honeycomb r?liuche

https://reviewboard.mozilla.org/r/26067/#review23435

::: mobile/android/base/BrowserApp.java:188
(Diff revision 1)
> +    private static final String PREF_HONEYCOMB_EOL_NOTIFIED = "honeycomb_eol_notified";

I updated this stringname to not be a PREF because while it's technically a pref, we don't need to consider it such.

::: mobile/android/base/BrowserApp.java:759
(Diff revision 1)
> +                        .setAutoCancel(true)

This got me stuck for a while, and the documentation doesn't say so, but appaerntly this notification won't show if you don't call setSmallIcon.

::: mobile/android/base/BrowserApp.java:769
(Diff revision 1)
> +                                .putBoolean(PREF_HONEYCOMB_EOL_NOTIFIED, false)

I updated this value to be "true", because we're checking for false to enter this loop.

::: mobile/android/base/BrowserApp.java:2399
(Diff revision 1)
> +        if (Versions.preICS && !Versions.preHC) {

I updated this check to be !preHC && !features14Plus, which translates to !gingerbread && !ICS-and-above.

::: mobile/android/base/locales/en-US/android_strings.dtd:748
(Diff revision 1)
> +<!ENTITY eol_notification_title "&brandShortName; no longer supports Android 3.0">

Still not sure if this should be 3.0 or 3.x, but I needinfo'd antlam about it.

Thanks! There were just a few things that didn't work, but since you don't have a device, I just fixed them and pushed a commit that I'll fold in rather than make you blindly write code that you couldn't test and then wait for me to test it.

Comment 42

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Comment on attachment 8691090 [details]
"3.x" messaging

Yeah, this is weirdly specific yet... not specific..

Comment 43

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Chenxia Liu [:liuche] from comment #37)
> Created attachment 8691088 [details]
> "3.0" messaging

I'm ok with just saying "3" instead of "3.0" since we're also not support 3.1 or 3.2, etc.. But it might not be a big deal.

(In reply to Chenxia Liu [:liuche] from comment #38)
> Created attachment 8691090 [details]
> "3.x" messaging
> 
> 1. Here's the messaging for 3.0 vs 3.x. I personally feel like 3.x looks a
> little weird, so asking you for feedback.

Yeah, let's not write "3.X"... there are many things that could mean "insert number here" like X, or *, I think this would just cause more confusion.

> 2. If you kill Fennec, the messaging goes away and does not return, even if
> you didn't click on it/read it. It should at least show up as a notification
> so the user could see it, but they might not. (We can add a DeleteIntent and
> listen for a Broadcast and only not show the notification if the user closes
> the intent or clicks on it, but this is a little more work and if you don't
> care, then let's not do it.)

I'm not strongly opinionated either way. 

Some users may actually not want to/be able to upgrade past Android 3 so persisting a notification like this indefinitely could be annoying anyways.

Comment 44

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/23460fa28bec

Comment 45

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/23460fa28bec

Comment 46

[Francesco Lodolo [:flod]]

Any technical reason to expose this URL as localizable? Because there's nothing that localizers should do with it, code resolves all variables on its own
http://hg.mozilla.org/mozilla-central/rev/23460fa28bec#l3.14

Comment 47

[:Margaret Leibovic]

(In reply to Francesco Lodolo [:flod] from comment #46)
> Any technical reason to expose this URL as localizable? Because there's
> nothing that localizers should do with it, code resolves all variables on
> its own
> http://hg.mozilla.org/mozilla-central/rev/23460fa28bec#l3.14

Looks like that was an oversight.

Can we get a follow-up to fix this? We should put this directly in strings.xml.in, like this:
http://hg.mozilla.org/mozilla-central/annotate/1835baed2a38/mobile/android/base/strings.xml.in#l86

Comment 48

[Chenxia Liu [:liuche]]

Sorry about that, I'll put up a patch for that.

Actually, Joni, do you know if the page is live, or if it's only live for some versions? Embarrassingly enough, I had never clicked on the link and when I tried it today, the page can't be found.

https://support.mozilla.org/1/firefox/45.0.a1/Android/en_US/honeycomb

Comment 49

[Chenxia Liu [:liuche]]

Reopening, because we need to fix this link.

Comment 50

[Chenxia Liu [:liuche]]

kar, can you let me know where you got the SUMO link for this EOL message, and would you doublecheck that it matches what was mentioned in comment #16? It doesn't seem to work and we need to fix it.

Comment 51

[Joni Chan]

@liuche, that link has one minor error. It should say "mobile" instead of "firefox", so the right link is https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/honeycomb

The content will be up by December 18th per https://mozilla.aha.io/features/FENN-366.

Comment 52

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/4ab468343328

Comment 53

[Chenxia Liu [:liuche]]

Thanks Joni!

I've updated the link, and unlocalized the string.

STR:
Notification should pop up on Honeycomb the first time it's opened with these changes (but it will only show up once - if it gets dismissed or Fennec is closed completely, it won't reappear again).
Clicking on the link should open up a SUMO page and dismiss the notification (the page will not be live until Dec 18).

Comment 54

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4ab468343328

Comment 55

[Teodora Vermesan (:TeoVermesan)]

Attachment: device-2015-12-07-155353.png

Tested using:
Device: Acer Iconia Tab A500 (Android 3.2.1)

I've installed an older version Nightly 42.0a1 (17-07) and updated to latest 45.0a1 (06-12).
A notification is displayed in the notification bar informing users that "Nightly no longer supports Android 3. Tap to learn more". Tapping it, opens a new tab with a sumo article: http://i.imgur.com/9vOkaFF.png

Comment 56

[Chenxia Liu [:liuche]]

Hi Joni, I was working with the Honeycomb bug again, and I was wondering if the link is live yet, or if the url we're using is somehow wrong. I'm still getting a 404, with this url generated by our string substitutions: https://support.mozilla.org/1/mobile/46.0a1/Android/en_US/honeycomb

Comment 57

[Joni Chan]

Hi Chenxia,

It looks like the locale part of the link is wrong. It's supposed to be "en-us" instead of "en_us".

I was asked in the AHA board not to publish the article yet, but as soon as I get the go-ahead, I will.

Comment 58

[Kevin Brosnan [Ex-Mozilla]]

You could point it at the staging server during the development cycle. https://support.allizom.org/en-US/