Set the prompted pref along with the enabled prefs so that we don't have
to detect setting the enabled pref elsewhere in order to set the
prompted pref.
DONTBUILD NPOTB
Android Studio (and IntelliJ) does not correctly handle &entity;
definitions in Android strings.xml files. Strings with entities (in
Fennec, all of them) are rendered in the IDE as blank. This patch
expands the entities when copying for use by Gradle, improving the IDE
integration.
MozReview-Commit-ID: 2T6CzoKc7v8
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
MozReview-Commit-ID: 4fCY504UgPu
This commit adds the GzipNonChunkedCompressingEntity which is necessary because
the telemetry servers don't support chunked uploading, which the built in
GzipCompressingEntity does.
I tested this on my local device and logs for successful uploads were sent for
both the testing gzip server as well as the official telemetry server. My data
correctly appears on the former and I did not check the latter.
MozReview-Commit-ID: 4bCNiRYyqFD
Added testGetDir to sanity check how the profile is set up for the test and
left it in as a bonus.
Additionally, changed access levels on the ensureParentDirs method because it
only needed to be `protected` for testing.
MozReview-Commit-ID: CDVQjyf3yP2
Additionally, we log some of the Exceptions thrown while retrieving the client
ID to make it clearer what is happening. The underlying GeckoProfile methods
ensure the profile path is not printed so we don't have to worry about leaking
that.
MozReview-Commit-ID: 3o0rvXDRZzM
Fennec enables sCaretsExtendedVisibility which uses
Appearance::NormalNotShown instead of Appearance::None to keep actionbar
shown during scrolling. This breaks selection mode update when the
positions of the carets are not changed after scrolling.
To fix this, we need to implement appearance recovering for selection
mode scrolling like we did for cursor mode in bug 1212732, and make
UpdateCaretsForSelectionMode() respects UpdateCaretsHint.
MozReview-Commit-ID: LkfUIGKHL0h
When using physical keyboards, we get key events on the UI thread. To
improve performance, and to support key listeners better, we should
switch the IC thread to the UI thread in that case.
Right now, processKey uses a IC-thread proxy in order to handle key
events on the UI thread. This patch makes it post the key event to the
IC thread and avoid the proxy entirely.
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.
Opt-in by adding --enable-gradle-mobile-android-builds.
Gradle dependencies (including the Android-Gradle plugin) are assumed
to be present. Local developers will fetch them from the jcentral
repository.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: 966XgddWgEu
When doCreateShortcut was first created, it also handled webapp intents. This required additional
work, meaning doCreateShortcut had to be run on the background thread. We now only
create an Android Intent, with no additional work, hence we can run directly on the UI thread.
MozReview-Commit-ID: BFrAuNfDiFj
Fennec enables sCaretsExtendedVisibility which uses
Appearance::NormalNotShown instead of Appearance::None to keep actionbar
shown during scrolling. This breaks selection mode update when the
positions of the carets are not changed after scrolling.
To fix this, we need to implement appearance recovering for selection
mode scrolling like we did for cursor mode in bug 1212732, and make
UpdateCaretsForSelectionMode() respects UpdateCaretsHint.
MozReview-Commit-ID: LkfUIGKHL0h
Opt-in by adding --enable-gradle-mobile-android-builds.
Gradle dependencies (including the Android-Gradle plugin) are assumed
to be present. Local developers will fetch them from the jcentral
repository.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: 966XgddWgEu
This fixes a crash, since Bug 1242213 removed the .App
<activity-alias> that browser_intent_class references.
I debated just updating the strings, and decided that it was best to
remove a pattern that is used only once in our codebase, even though
it moves more functionality to code.
MozReview-Commit-ID: 4Wgw0oITgue
When Java is changing the composition, we should ignore the Gecko
selection. However, when Gecko is committing its composition, we should
not be ignoring the corresponding Gecko selection change. In other
words, we should only ignore selection changes when we know the change
is from Java.
See
https://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html
for a thorough discussion.
It's very expensive (at least 200ms on modern devices) to do this in
Application.onCreate, so we'll do this just before generating DSA keys.
In exchange, we accept some risk that we'll introduce the same issue
again. As we lint more aggressively in automation, this risk will
decrease.
Google licenses the fixes file very permissively. I have added some
serialization IDs to prevent certain compile warnings.
This patch adds 2 workarounds for the fact that getProfileCreationDate
returns -1 when it can't find a creation date. Returning -1 turned
out to be not particularly robust but I did it this way to avoid
adding too many additional versions of methods in order to have
optional parameters such as profileCreationDate. The workarounds
are added as TODOs w/ bug #'s in the code and mentioned in the
comments of bug 1246816 itself.
A future implementation should probably add a Builder to pass a
single Object as the argument to TelemetryPingGenerator.createCorePing
to prevent the argument list from growing unreasonably large and
to properly operate on optional parameters. I didn't do this in
this patch in order to simplify the uplifted code.
Retrieving the profile creation date from the filesystem is not strictly
necessary to upload this data and returns -1 until it is implemented. If the
decision is r+'d here, it will be implemented in bug 1246816.
On a CLOSED TREE because this is Android only.
When we switched to fine-grained Google Play Services bundling (Bug
1115004), we stopped shipping com.google.android.gms.analytics. That
silently breaks Adjust, which queries the Google Ad ID using
reflection: now the package isn't present! This patch restores the
Play Services libraries that Adjust relies on. (Sadly, this bloats
our APK tremendously.)
There is some hijinkery, however: the Play Services libraries
reference a library (org.apache.http) that is deprecated in Android
23! However, the library is still present on Android 23 devices,
which buys Google time to replace the offending code. This compiles
just fine, breaks the Proguard global optimization pass. To give
Proguard the information, we add the library as a Proguard "library
JAR". This is equivalent to the Google-provided Gradle `useLibrary`
directive.
This commit produces an "install bouncer" APK which is a "hollow
shell" that looks like the main Fennec APK. In particular, both APKs have:
* the same Android package name (application id); and
* the same set of <permission>, <uses-permission>, and <uses-feature>
blocks in their manifests.
The bouncer APK must always have an android:versionCode smaller than
the main Fennec APK; for now, we will just bump that manually
mobile/android/bouncer/moz.build.
Call a distribution in /data/data/$PACKAGE/distribution a "data
distribution". Right now we read data distributions only in response
to writing them via another code path (extracting from APK, or
downloading). We don't recognize a data distribution in the same way
that we recognize a system distribution (in /system/.../distribution)
in the Java code, simply because we don't look for it; and I haven't
investigated, but I think that Gecko may in fact recognize a data
distribution in this case.
This patch simply recognizes data distributions after looking for
other distributions. That way data distributions written by the
bouncer APK are recognized and initialized, but not given precedence
over other distribution channels.
This works due to string conversions, but it's not elegant. Let's
just define the API we want, and work to improve the implementation
when we remove org.json.simple entirely.
MozReview-Commit-ID: GseI427PeDi
One step further on the path of removing dependence on
org.json.simple: don't expose its exceptions to consumers of EJO. We
re-purpose the existing UnexpectedJSONException classes to incorporate
what were once ParseException instances.
MozReview-Commit-ID: KOwM3cf0fm
This is safe because the single consumer of `MetaGlobal.fetch` is
`FetchMetaGlobalStage.execute`, which already expects to be called on
a thread and have another thread waiting for the callback.
MozReview-Commit-ID: 5XXd5aBkljc
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
Enable building with Gradle using --with-gradle. Configure the
location of Gradle with --with-gradle=/path/to/gradle. For local
developers, this is always the in tree Gradle wrapper, which downloads
and installs the correct Gradle version automatically. In automation,
this will be a version of Gradle fetched from tooltool.
Configure the location to use to download Gradle Maven dependencies
(including the Android-Gradle plugin) by setting
GRADLE_MAVEN_REPOSITORY in your mozconfig. For local developers, this
defaults to the jcenter repository. In automation, this will be an
archived directory fetched from tooltool.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: Hrkn88Vig5H
This patch will prevent Firefox from downloading OMA download descriptors on
its own. Instead it will prompt to complete the action with an external app
if available. An error will be shown if no external app can handle the download.
On a CLOSED TREE
I don't understand why I didn't see this in local testing or try
builds, but I didn't. Simple enough: we now load a distribution from
/data/data as a matter of course, which means that tests that install
such a distribution need to remove it when they are done. This patch
does that.
On a CLOSED TREE.
So, apparently we race to have a non-null application context from the
target context. No matter, we can use the target context directly.
DONTBUILD NPOTB
Using the real Android manifest tripped up Robolectric, so I've taken
the easy way out and added a dummy TestGeckoApplication; see comment
in the code.
ON A CLOSED TREE
I have manually verified that this results in a byte-identical
gecko.ap_. This is because after the earlier patches there are no
definitions (or aliases) that are package-local (like .App or
.Webapp), which are the only things (other than the Android package
name) that get rewritten by --rename-manifest-package.
Way back in Fennec 33 (Bug 929865, see
https://hg.mozilla.org/mozilla-central/rev/a4f39c9db1d9) we replaced
org.mozilla.gecko.App with org.mozilla.gecko.BrowserApp and introduced
the .App <activity-alias>. Per the entry for android:name of
http://developer.android.com/guide/topics/manifest/activity-element.html,
.App translates to $ANDROID_PACKAGE_NAME.App. We haven't referenced
an Activity qualified with a non-org.mozilla.gecko *class* name (for
example, from bookmark shortcuts) since well before Fennec 33, so this
probably never did what it was intended to do: we wanted to redirect
org.mozilla.gecko.App to org.mozilla.gecko.BrowserApp, but it instead
has been redirecting org.mozilla.fennec.App to
org.mozilla.gecko.BrowserApp. I don't think we've been referring to
$ANDROID_PACKAGE_NAME.App since well before Fennec 29, if ever.
The <activity-alias> has been servicing essentially all
<intent-filter> invocations of Fennec by passing them directly to
org.mozilla.gecko.BrowserApp.
This pushes a long programme of simplification forward. Fallout might
look like very old homescreen shortcuts failing to launch, but I'm
quite confident that won't actually happen.
This <activity> and <activity-alias> support old-style homescreen
shortcuts to old-style Webapps. Such shortcuts must have been
produced at least 18 months ago, and pre-date the new-style synthetic
APK Webapps entirely. New-style APK Webapps are slated to be removed
from the product entirely, and there's no reason to keep their even
less viable predecessor around.
Telemetry from http://mzl.la/23kXGV5 shows that there were no launches
of webapps (old-style or new-style) for Fennec 43 release. Telemetry
from http://mzl.la/23kXFAs shows that there were 40.7k launches of
webapps (again, old-style or new-style) for Fennec 44 beta (of 39.0M
total -- for 0.1% total). We cannot distinguish old-style from
new-style, but it is safe to assume it's a tiny proportion.
Users with such homescreen shortcuts will see a bogus "App isn't
installed" message and need to delete and re-create their shortcut in
some way.
The org.mozilla.gecko.Webapp class cannot be removed until new-style
APK Webapps are removed.
This small change is a follow-up to Bug 1242213, which did the same
for the main package. This is a nod to the future and Gradle, which
cleanly splits the internal Java package (org.mozilla.gecko) from the
external Android package (org.mozilla.fennec and friends).
This commit produces an "install bouncer" APK which is a "hollow
shell" that looks like the main Fennec APK. In particular, both APKs have:
* the same Android package name (application id); and
* the same set of <permission>, <uses-permission>, and <uses-feature>
blocks in their manifests.
The bouncer APK must always have an android:versionCode smaller than
the main Fennec APK; for now, we will just bump that manually
mobile/android/bouncer/moz.build.
Call a distribution in /data/data/$PACKAGE/distribution a "data
distribution". Right now we read data distributions only in response
to writing them via another code path (extracting from APK, or
downloading). We don't recognize a data distribution in the same way
that we recognize a system distribution (in /system/.../distribution)
in the Java code, simply because we don't look for it; and I haven't
investigated, but I think that Gecko may in fact recognize a data
distribution in this case.
This patch simply recognizes data distributions after looking for
other distributions. That way data distributions written by the
bouncer APK are recognized and initialized, but not given precedence
over other distribution channels.
This reads from "assets/distribution/**" in the APK and writes to
"distribution/**" in the data directory. That output is the same, but
the input used to read from "distribution/**", which is not really
supported by modern build tooling (Gradle), which doesn't allow to
write files directly into the APK root.
I manually tested this without issue. I see no way to add meaningful
tests to our current Robocop test suite; the long term testing
approach is to develop a new test for this functionality and only run
it against the "distribution" build type that was added in Bug
1163080. However, that's a larger project than I have time for now.
This simply packs the assets/ subdirectory of the distribution
directory into the assets/ directory of the Android APK using existing
mechanisms. It also removes the older method of manually pushing
files into dist/bin/distribution, from where they would be packaged
into the APK under distribution/.
This reads from "assets/distribution/**" in the APK and writes to
"distribution/**" in the data directory. That output is the same, but
the input used to read from "distribution/**", which is not really
supported by modern build tooling (Gradle), which doesn't allow to
write files directly into the APK root.
I manually tested this without issue. I see no way to add meaningful
tests to our current Robocop test suite; the long term testing
approach is to develop a new test for this functionality and only run
it against the "distribution" build type that was added in Bug
1163080. However, that's a larger project than I have time for now.
This simply packs the assets/ subdirectory of the distribution
directory into the assets/ directory of the Android APK using existing
mechanisms. It also removes the older method of manually pushing
files into dist/bin/distribution, from where they would be packaged
into the APK under distribution/.
A few notes: the test is live, so I've marked it @Ignore, so that it
doesn't run during |mach gradle test|. There's some value in mocking
the service endpoint, but this is how I verify that the server works,
so it has more value right now as a live test than a mocked test. In
the future, that probably won't be true.
There are issues running the test locally because Robolectric doesn't
provide all the cipher suites we use in GlobalConstants: in
particular, the GCM suites aren't supported. This may improve as
Robolectric matures, or we may add a work-around in the code (like at
http://androidxref.com/4.4.4_r1/xref/libcore/support/src/test/java/libcore/java/security/StandardNames.java#68),
or we may add a test-specific flag. For now, I'm not going to address
it directly.
Finally, I put the code in mobile/android/services, simply because the
less that goes into base, the better our build times will be.
This seems more consistent with what Android UI callbacks do. This commit also
means all callees must be adapted to use the background thread if needed.
