1343725 - Disable INTL_API on Android release build

Status: RESOLVED FIXED

(Firefox Build System :: Android Studio and Gradle Integration, enhancement)

Description

[Makoto Kato [:m_kato]]

- Even if test is failure, we turn off INTL_API on release build now.
- Re-implement DateTimeFormater for non-INTL_API build
- After re-implementing it, turn off INTL_API on Android/x86 only even if not released build (for test)

Comment 1

[Tooru Fujisawa [:arai]]

does it mean Intl API won't be available on release build?
in that case the documentation should be updated.

Comment 2

[Makoto Kato [:m_kato]]

(In reply to Tooru Fujisawa [:arai] from comment #1)
> does it mean Intl API won't be available on release build?
> in that case the documentation should be updated.

Yes, this is current decision.  But it won't be final.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

Can you provide some timeline for this? (timeline for when we'll be able to release Android with ICU and get rid of the non-ICU codepaths)

I'm working on a lot of elements that rely on INTL_API like LocaleService (with language negotiation), OSPreferences, mozIntl, L10nRegistry.

Comment 4

[Makoto Kato [:m_kato]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #3)
> Can you provide some timeline for this? (timeline for when we'll be able to
> release Android with ICU and get rid of the non-ICU codepaths)
> 
> I'm working on a lot of elements that rely on INTL_API like LocaleService
> (with language negotiation), OSPreferences, mozIntl, L10nRegistry.

:snorp, could you answer it?

Comment 5

[Jan Henning [:JanH]]

In that case bug 1200494 part 1 (https://hg.mozilla.org/mozilla-central/rev/e07ec12de6c0) will need backing out again.

Comment 6

[Masatoshi Kimura [:emk]]

Do we leave untested-until-it-reaches-beta code path indefinitely? I don't think it works well.
We should either:
1. Stand-up Intl/non-Intl jobs in automation (like e10s/non-e10s), or
2. Disable Intl on Android completely.

Comment 7

[Makoto Kato [:m_kato]]

For test,

- I will add skip-if for some xpshell test such as test_localeCompare.js.
- mochitest doesn't run on android-x86, so even if android-x86's all build turns off INTL API, we don't cover all tests on android-api-15.  (Maybe, snorp or blassy misunderstands it)
- I will add skip code for mochitest's interface tests such as test_interfaces.html
- gtest doesn't run on all Android.  So we can ignore this
- Like comment #5, we need back out it. (for test_DownloadUtils.js)

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

I don't think there is a specific timeline for when we'll be able to ship ICU on Android. It will depend on the efforts to get the APK size down.

Comment 9

[Jan Henning [:JanH]]

I've tried disabling the Intl API on Nightly for testing purposes, but all I'm getting is a busted build:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2526287a0ae6f91bf736c726d9f79d56c649e150

Is that to be expected because of bug 1343766, or is this something else that need reverting again?

Comment 10

[Makoto Kato [:m_kato]]

(In reply to Jan Henning [:JanH] from comment #9)
> I've tried disabling the Intl API on Nightly for testing purposes, but all
> I'm getting is a busted build:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=2526287a0ae6f91bf736c726d9f79d56c649e150
> 
> Is that to be expected because of bug 1343766, or is this something else
> that need reverting again?

bug 1344596 and bug 1343766

Comment 11

[Jan Henning [:JanH]]

Builds pass, but there are at least some xpcshell failures.

Comment 12

[Jan Henning [:JanH]]

Forgot the link:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=68413037ea33b83c9cd2ecec8ebe8212fa28786f

Comment 13

[Henri Sivonen (:hsivonen)]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #8)
> I don't think there is a specific timeline for when we'll be able to ship
> ICU on Android. It will depend on the efforts to get the APK size down.

Is there some documented criterion for the APK size and some documented rationale for that criterion? Is there an ongoing effort to slim down the non-libxul parts of the APK?

Comment 14

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Henri Sivonen (:hsivonen) from comment #13)
> (In reply to James Willcox (:snorp) ([e-mail]) from comment #8)
> > I don't think there is a specific timeline for when we'll be able to ship
> > ICU on Android. It will depend on the efforts to get the APK size down.
> 
> Is there some documented criterion for the APK size and some documented
> rationale for that criterion? Is there an ongoing effort to slim down the
> non-libxul parts of the APK?

There may be some documented rationale somewhere, but AFAIK there is no target number. Only that "smaller is better". My understanding is that there are ongoing conversations right now with product/BD about this.

Comment 15

[Zibi Braniecki [:zbraniecki][:gandalf]]

One such effort is led by me in tracking bug 1347797. The bug itself is deceivingly calm, but look at the dependency tree.

Comment 16

[Tooru Fujisawa [:arai]]

I'll change the documentation listed in bug 1215247 comment #104 to say it's nightly-only.

Comment 17

[Tooru Fujisawa [:arai]]

updated:
  https://developer.mozilla.org/en-US/Firefox/Releases/54

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/localeCompare

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/prototype
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/supportedLocalesOf
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/compare
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Collator/resolvedOptions

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/prototype
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/supportedLocalesOf
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/format
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/resolvedOptions

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/prototype
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/supportedLocalesOf
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/format
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/resolvedOptions

  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales

Comment 18

[Makoto Kato [:m_kato]]

all issues are closed and this is meta bug.  So I close this.

Comment 19

[Chris Mills [:cmills]]

Thanks for the docs!