Android layers on Jolla C2

Noob here. Not to tech, but to Jolla and the upcoming C2. I do have some questions; pointers or even answers are appreciated :slight_smile:

  • from one of the first articles in this thread I saw that Android 13 had an impact on how Jolla can implement Telephony. Does that mean that there’s still Android in this device deep down there? (I am looking to get de-googled as far as sensible);
  • The Reeder device type was mentioned, I found the (partial?) specs but is there a way to do a biometric authentication factor? Did not see a fingerprint sensor, for example.
  • would the Android compatibility software be available to help for those few things that cannot be done without an Andoird app?
  • related: Would Bluetooth be available to Android Apps? I am keen on switching over to passkeys and I understood that BT connectivity between phone and workstation would be beneficial to that. Unless of course this can be made to work natively.

I think this might be a pretty fat first posting - again pointers to fact sheets or other relevant literature are useful already (but I did not find them). Thx to whom it concerns!

Brgds,
Willem

2 Likes

regarding fingerprint

most of your questions might be answered in that thread

and googeling for why needs sfos android i got that hit:

hope that helps

2 Likes

Welcome to the forum @willem_b!

there’s still Android in this device deep down there

In some way. The lack of linux peripherals support for mobile SoCs is because vendors only ship some binary services that “know” how to interact with the hardware, and expose that as an android binder/AIDL/HIDL etc. interface. Basically Sailfish when adapted to such devices uses that “android-targeted” vendor layer as last resort.

is there a way to do a biometric authentication factor

I don’t see any, either, and no reference to one being under screen (which I don’t think would work for LCD).

would the Android compatibility software be available

Not sure if they announced anything special about AppSupport, I would hope it just gets included by default.

to help for those few things that cannot be done without an Android app

Yes, except Bluetooth support other than audio routing and NFC. (and Google Play services, and Safetynet etc everything like on an unlocked device)

Hmm… I can understand how something you know / something you have could be extended to something you’re in the proximity of, but I highly doubt that “having both devices connected to each other through bluetooth and to the internet” is the future of password security (not mentioning involving closed source apps over which you get not to peek over such as unrooted Android)
But the answer is No (because no bluetooth AppSupport), unless there’s a standard for that and we can make a Sailfish app for it.

6 Likes

I hope Reeder will come with a cover. I always used a cover to protect my phone.

4 Likes

Maybe an exclusive Jolla Sailfish Cover

6 Likes

To go into details, it’s multiple layers:

  • at the bottom of the layers, the manufacturer of the chipset (e.g. Qualcom) usually only produces drivers that are designed to run in Android (including some of the unusual library and interface that Android runs unlike other Linux based OS)
  • on top of the hardware SailfishOS is relatively standard GNU/Linux distro (audio handled with pulseaudio, graphics with waydroid, etc. has a standard C library)
  • Jolla use a special compatibility layer (libhybris) that makes the android-only driver usable in the classic Linux distro such as SailfishOS.
  • on top of the OS, you can run native Linux apps, mostly written using Qt and QML graphics.

so the only mandatory bits are the drivers written by the chipset manufacturer.

If you want to run android apps:

  • Jolla provides a compatibility layer called Android App Support. It’s an LXC container (mostly like Docker containers) that you can optionnally download and install from the Jolla’s application store.
  • you you start this container (there’s an entry in Setting), AOSP runs inside (the opensource-only parts of Android, without the proprietary Google Bit).
    • this makes some Android apps possible to run. You’ll most probably rely on F-Droid to download (open source) Android apps.
  • optionally you can install microG, it’s an opensouce re-implementation of “Google Play Service” the API that are normally provided by the proprietary Google Bit.
    • this makes a lot more apps possible to run. You can use the opensource Aurora (installable from F-Droid) to download and install apps from Google’s own Store.
    • some apps might still refuse to run due to some specific things that the original proprietary Google Play Service provides, but which are missing in microG (e.g.: some Banking app might complain about a rooted device, because they want a full Google SafetyNet remote attestation).
  • optionally you can also install isntead the original Google Play Service.
    • this kind of defies your de-googling attempts.
    • but this makes the stuborn e-banking app workable
    • (also, you don’t need to constantly run the container. You can keep the container not running, and only run the container for when you need “that one” android app you can’t find a replacement for)

A big difference between a stock Android OS, and Android App Support is that you get more options to control what is running in the phone (even more if you opt to use microG instead of Google’s own shit).
e.g.:

  • you can manually start Android App Support yourself (and only run native SailfishOS apps the rest of the time).
  • you can configure Android App Support to not start applications in background on startup.
  • you can configure microG to not automatically start an application when that gets a message/alert from the cloud servers.

Also:

  • the AOSP running inside the container cannot see and use the hardware of the phone. For technical reasons in needs special supports that expose stuff to Android.
  • e.g.: you can plug an USB keyboard or pair a Bluetooth keyboard, and Android will see an available “input device”.
  • e.g.: you can pair Bluetooth speaker, and Android will see an available “audio out”
  • BUT there’s currently no support for Bluetooth itself, so you cannot use an Android apps that needs to directly talk to a bluetooth device (you cannot use the speaker manufacturer’s app to flash a firmware update to the bluetooth speaker).

On smartphones not officially supported by Jolla, there is the opensource Waydroid solution which is pretty similar to Android App Support.

  • The main differences are in what adapters each has (e.g.: Waydroid currenlty cannot open multiple windows on SailfishOS)

So TL;DR: You get a whole range of option between:

  • only the hardware drivers written by Qualcom
  • more or less support for apps with some containers and optional service replacement (and you can aprevent apps running in background).
  • full(-er -ish) compatibility by replicating a full android, but at least you get to shut it down when no in use.
44 Likes

Nice summary! Thank you!

1 Like

Thanks! This was a nice reminder of the subsystems in play. I often forget that the App Support layer is an LXC container, even though I’m an LXC fan!

3 Likes

Thank you for this clear explanation!

Technically, it is really cool.

1 Like

I never used microG but I use Aurora store for the apps, I cannot find in Fdroid. And most of the apps are running fine, even my banking app.

2 Likes

I was not aware of that possibility:

How can I achieve that?

Directly in the setting (of Sailfish OS) of the Android app.

2 Likes

Your insights would be a great addition to the SFOS Wiki: https://sailfishos.wiki/ (which is soon™ to be hosted by Sailmates)

5 Likes

@DrYak that was a magnificent response - thanks a lot!