Running Fennec/GeckoView on AOSP without SystemUI

Hi all,

here’s the instructions on how to run a Fennec/GeckoView on a AOSP without SystemUI. It took me a while, but luckily the solution is luckily easier than expected.

First make sure you have a proper ASOP built from source. I used Nougat on the X86_64 emulator. You also need a to build Firefox for Android (Fennec) from source.

If you have both, apply the two patches below. This one for ASOP. It’s just removing SystemUI, Home, Launcher2 and Launcher3 from the build:

diff --git a/target/product/core.mk b/target/product/core.mk
index 75cf649..a342663 100644
--- a/target/product/core.mk
+++ b/target/product/core.mk
@@ -41,7 +41,6 @@ PRODUCT_PACKAGES += \
     KeyChain \
     Keyguard \
     LatinIME \
-    Launcher2 \
     ManagedProvisioning \
     MtpDocumentsProvider \
     PicoTts \
diff --git a/target/product/core_base.mk b/target/product/core_base.mk
index 03d33e1..e4e3a7b 100644
--- a/target/product/core_base.mk
+++ b/target/product/core_base.mk
@@ -23,7 +23,6 @@ PRODUCT_PROPERTY_OVERRIDES := \
 PRODUCT_PACKAGES += \
     ContactsProvider \
     DefaultContainerService \
-    Home \
     TelephonyProvider \
     UserDictionaryProvider \
     atrace \
diff --git a/target/product/generic_no_telephony.mk b/target/product/generic_no_telephony.mk
index 5c48358..3fe18e3 100644
--- a/target/product/generic_no_telephony.mk
+++ b/target/product/generic_no_telephony.mk
@@ -26,7 +26,6 @@ PRODUCT_PACKAGES := \
     MusicFX \
     OneTimeInitializer \
     Provision \
-    SystemUI \
     EasterEgg \
     WallpaperCropper
 
diff --git a/target/product/sdk_base.mk b/target/product/sdk_base.mk
index fa257ae..62fa2de 100644
--- a/target/product/sdk_base.mk
+++ b/target/product/sdk_base.mk
@@ -26,7 +26,6 @@ PRODUCT_PACKAGES := \
    Fallback \
    Gallery \
    GestureBuilder \
-	Launcher3 \
    LegacyCamera \
    librs_jni \
    libwnndict \
@@ -43,7 +42,6 @@ PRODUCT_PACKAGES := \
    SmokeTestApp \
    SoftKeyboard \
    sqlite3 \
-	SystemUI \
    EasterEgg \
    WidgetPreview

And that one for Fennec and GeckoView. It just makes them launchers:

diff --git a/mobile/android/base/AndroidManifest.xml.in b/mobile/android/base/AndroidManifest.xml.in
index 295f7f4..300dea8 100644
--- a/mobile/android/base/AndroidManifest.xml.in
+++ b/mobile/android/base/AndroidManifest.xml.in
@@ -82,6 +82,7 @@
                 <category android:name="android.intent.category.MULTIWINDOW_LAUNCHER"/>
                 <category android:name="android.intent.category.APP_BROWSER" />
                 <category android:name="android.intent.category.DEFAULT" />
+                <category android:name="android.intent.category.HOME" />
             </intent-filter>
 
             <intent-filter>
diff --git a/mobile/android/geckoview_example/src/main/AndroidManifest.xml b/mobile/android/geckoview_example/src/main/AndroidManifest.xml
index 551a4a7..548686c 100644
--- a/mobile/android/geckoview_example/src/main/AndroidManifest.xml
+++ b/mobile/android/geckoview_example/src/main/AndroidManifest.xml
@@ -8,9 +8,13 @@
         <uses-library android:name="android.test.runner" />
 
         <activity android:name="org.mozilla.geckoview_example.GeckoViewActivity"
-                  android:label="GeckoViewActivity">
+                  android:label="GeckoViewActivity"
+                  android:theme="@android:style/Theme.Wallpaper.NoTitleBar.Fullscreen"
+                  android:launchMode="singleTask"
+                  android:stateNotNeeded="true">
             <intent-filter>
                 <action android:name="android.intent.action.MAIN" />
+                <category android:name="android.intent.category.HOME" />
                 <category android:name="android.intent.category.DEFAULT" />
                 <category android:name="android.intent.category.LAUNCHER" />
             </intent-filter>

Now you need to rebuild them. For ASOP do:

make installclean
make

If you start the emulator via:

emulator -gpu swiftshader

you should get in the adb logcat output something like

10-20 16:44:07.316  1987  1987 D FallbackHome: User unlocked but no home; let's hope someone enables one soon?

repeatedly. You can now install a launcher (homescreen). Either Fennec or Geckview.

For Fennec run from without your Gecko source directory:

./mach build
./mach package
./mach install
# to uninstall
adb uninstall org.mozilla.fennec_${USER}

If you want to install GeckoView, then go into mobile/android/geckoview_example and run:

../../../gradlew build
../../../gradlew installWithGeckoBinaries
# to uninstall
../../../gradlew uninstallWithGeckoBinaries
10 Likes

Thanks Volker for looking into this!
I get the same results on a Nexus 5 aosp build. I then tried the next logical step: directly shipping fennec or the geckoview example as part of the build, instead of installing afterwards.
In this configuration we fail to start because of some issue with our custom dynamic linker. I’m gonna dig into that these coming days. I’m pretty sure this is fixable, as this changed between gecko 46 and current (52). I tried with a gecko46 b2gdroid apk and it started just fine…

4 Likes

Good news, I now have fennec starting properly. See the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1312545 for details.

Next step: revive something like b2gdroid…

2 Likes

Nice work @fabrice! I am most interested in the telephony stack. That probably isn’t that easy. My guess is the some (hopefully a lot) of the RIL code can be re-used. It also probably makes sense to do that on a real phone (which I’ll luckily will get soon :slight_smile: Any general pointers on how this might be done best are welcomed (as I e.g. also don’t know if we should re-use the B2G code or use something else from the other mobile efforts).

PS: I probably won’t have much time to work on this for the next 3 weeks, but expect some more work from me afterwards again.

The idea is to create servers running on the phone to handle the native functionality like telephony. Those would talk over WebSockets and/or expose a plain (RESTful?) API so that pages can invoke the necessary functionality without adding anything to gecko. We’ve discussed re-using the RIL code in the past and concluded it would be quite tricky. It might be better to start over.

I think developing server is a good one as others may also benefit from it. When I look at Gecko’s RIL stuff, it looks like a lot of code. Is the problem the code itself, that it is coupled to Gecko or that using RIL directly isn’t a good idea?

After a quick search I found the Sailfish oFono fork, which would be an alternative to talking to RIL directly. For those knowing as little about the whole topic as I do, SailfishOS has some nice documentation on their telephony stack.

Does anyone have a recommendation on what to use?

Is the problem the code itself, that it is coupled to Gecko or that using RIL directly isn’t a good idea?

Using the RIL directly is not an issue IMHO; the issue with our current code is that it’s very Gecko-specific with the APIs implemented over Gecko’s IPC mechanisms. It’s not really suitable for re-purposing though we can use it as a reference.

Also when we start tackling telephony it would be great to have the latest drafts of the telephony APIs that were presented right before the cancellation of the project last year in Orlando. We wouldn’t implement them directly anymore but the abstractions they provided where very polished, the result of years of refinements, so they would be a very good for a new design. I’ll try pinging the people involved and see if they still have them laying around.

1 Like

Thanks @fabrice and @vmx ! Is this architecture design by @benfrancis still valid? Where would be the window manager? As a service / is it missing a single-app / or a parent html page hosting iframes / views (as angular would do with a “sticky router”)?

the system app continues to take the role as a window manager as it has been with Gecko + Gonk

Hey, @vmx, have you seen this thread? It’s perhaps not very well titled, but it has a lot of discussion about servers/services, etc.

Concerning ofono in Android/bionic land, I have seen an ofono fork somewhere that had an Android.mk file, and built ok with bionic. I think though that using it in Androidland will probably come with a lot of unexpected and upleasant surprises. Would it not be worthwhile to also consider writing a service in Java that hooks instead into Android’s existing telephony APIs? At least while other options are explored, this could be a stand-in.

@vmx This is very interesting, well done getting it working. My technical skills are a way off attempting this myself but it’s something to work towards.
Cheers :slight_smile: