Currently, all versions of Firefox run with the existing native
Firefox Account UI. This flag will opt-in to maintaining that
experience while we transition to a web account UI. Once we're stable
on the web, we'll remove this flag entirely.
This patch assumes that Android M is going to be API level 23 (very likely) and additionally
checks for Android M Preview builds (Build.VERSION.RELEASE set to "M").
Rather than hardcoding the following classes in AppConstants.java.in and AndroidManifest.xml, they are set in
confvars.sh:
org.mozilla.gecko.GeckoApplication (Specified using MOZ_ANDROID_APPLICATION_CLASS)
org.mozilla.gecko.BrowserApp (Specified using MOZ_ANDROID_BROWSER_INTENT_CLASS)
org.mozilla.search.SearchActivity (Specified using MOZ_ANDROID_SEARCH_INTENT_CLASS)
I replaced the compile-time ANDROID_PACKAGE_NAME with the run-time
context.getPackageName() for two reasons:
1) I claim this is more correct. It's hard to imagine Fennec working
with ANDROID_PACKAGE_NAME != context.getPackageName(), but right here
we should use the run-time, not the build-time state.
2) GeckoLoader is part of GeckoView, and as such it shouldn't assume
anything about the package it's running as.
GeckoView consumers may ship for multiple architectures, so we
shouldn't assume anything about the build-time architecture, but the
reference to MOZ_CPU_ABI is purely diagnostic. There are substantive
changes to make here; we'll cross that bridge some other time.
The constants JAR contains AppConstants and SysInfo. SysInfo depended
on HardwareUtils for one function, which can (should?) be in SysInfo
anyway, so I moved it.
Both SysInfo and AppConstants should be available to Robocop tests,
but they are compiled too early to access RobocopTarget. Since
nothing in GeckoView should know about GeckoView, I moved the
annotation to the Fennec-level proguard.cfg.
I replaced the compile-time ANDROID_PACKAGE_NAME with the run-time
context.getPackageName() for two reasons:
1) I claim this is more correct. It's hard to imagine Fennec working
with ANDROID_PACKAGE_NAME != context.getPackageName(), but right here
we should use the run-time, not the build-time state.
2) GeckoLoader is part of GeckoView, and as such it shouldn't assume
anything about the package it's running as.
GeckoView consumers may ship for multiple architectures, so we
shouldn't assume anything about the build-time architecture, but the
reference to MOZ_CPU_ABI is purely diagnostic. There are substantive
changes to make here; we'll cross that bridge some other time.
The constants JAR contains AppConstants and SysInfo. SysInfo depended
on HardwareUtils for one function, which can (should?) be in SysInfo
anyway, so I moved it.
Both SysInfo and AppConstants should be available to Robocop tests,
but they are compiled too early to access RobocopTarget. Since
nothing in GeckoView should know about GeckoView, I moved the
annotation to the Fennec-level proguard.cfg.
I replaced the compile-time ANDROID_PACKAGE_NAME with the run-time
context.getPackageName() for two reasons:
1) I claim this is more correct. It's hard to imagine Fennec working
with ANDROID_PACKAGE_NAME != context.getPackageName(), but right here
we should use the run-time, not the build-time state.
2) GeckoLoader is part of GeckoView, and as such it shouldn't assume
anything about the package it's running as.
GeckoView consumers may ship for multiple architectures, so we
shouldn't assume anything about the build-time architecture, but the
reference to MOZ_CPU_ABI is purely diagnostic. There are substantive
changes to make here; we'll cross that bridge some other time.
The constants JAR contains AppConstants and SysInfo. SysInfo depended
on HardwareUtils for one function, which can (should?) be in SysInfo
anyway, so I moved it.
Both SysInfo and AppConstants should be available to Robocop tests,
but they are compiled too early to access RobocopTarget. Since
nothing in GeckoView should know about GeckoView, I moved the
annotation to the Fennec-level proguard.cfg.
