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 approach lets us get rid of the .App <activity-alias> definitions, at
least.
In Bug 1237755, I tried pretty hard to use real intent filters, rather
than a different hard-code path name, but ran into significant issues,
and finally into the hard reality that Android 2.3 doesn't support
bare package names. (It only supports package/class component names.)
Android 2.3 can't die fast enough.
Sadly, this approach doesn't address the issues I see loading URLs
that prompted Bug 1237755.
This is the path of least resistance. Onwards!
Tested via:
nalexander@chocho ~/M/gecko> ./mach run
Starting: Intent { act=android.activity.MAIN cmp=org.mozilla.fennec_nalexander/org.mozilla.gecko.BrowserApp }
Warning: Activity not started, its current task has been brought to the front
nalexander@chocho ~/M/gecko> ./mach run https://mozilla.org
Starting: Intent { act=android.activity.MAIN dat=https://mozilla.org cmp=org.mozilla.fennec_nalexander/org.mozilla.gecko.BrowserApp }
nalexander@chocho ~/M/gecko> ./mach run file:///mnt/sdcard/test.html
Starting: Intent { act=android.activity.MAIN dat=file:///mnt/sdcard/test.html cmp=org.mozilla.fennec_nalexander/org.mozilla.gecko.BrowserApp }
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/.
While waiting for a fix at test harness level, added a helper waiting for MozAfterPaint
when running in e10s mode for all the browser_profiler_tree-abstract tests.
While investigating bug 1243549, we encountered several instances of the following error message during each startup:
*************************
A coding exception was thrown and uncaught in a Task.
Full message: TypeError: this.Paths is null
Full stack: Agent.wipe@resource:///modules/sessionstore/SessionWorker.js:296:7
worker.dispatch@resource:///modules/sessionstore/SessionWorker.js:21:24
anonymous/AbstractWorker.prototype.handleMessage@resource://gre/modules/workers/PromiseWorker.js:122:16
@resource:///modules/sessionstore/SessionWorker.js:30:41
*************************
These messages can be explained as follows:
* If sanitization has failed during shutdown, it attempts again to
sanitize during startup. This happens more often than it used to,
because of 1/ startup bug fixes in bug 1089695; 2/ new shutdown bugs
most likely also added by or around bug 1089695.
* Sanitization during startup doesn't wait until Session Restore has
properly started to sanitize the session. So sanitization of Session
Restore file fails. This has probably always been the case, except
we never noticed.
* For some reason I do not understand, it attempts to sanitize several
times.
* I suspect that this can cause problems during startup, as
sanitization and Session Restore race to use/remove the files of
Session Restore.
This patch makes sure that SessionFile.wipe() waits until
initialization of SessionFile is complete before proceeding.
gDevTools.jsm isn't properly reloadable as JSM as meant to be long-lived singletons.
Also, it contains browser related code (gDevToolsBrowser) mixed with more generic one (gDevTools).
This move is going to help hot reloading devtools codebase while improve readability of
one of our core piece of code (devtools startup and browser hooks).
