OsmAnd via Android Auto - a practical and privacy-friendly offline navigation solution?

Posted on 15 August, 2022 at 15:40 UTC by Daniel Kulesz

Category: meta

Modern cars are equipped with headunits that support Android Auto or Apple Carplay. With the recently added support for Android Auto in OsmAnd - an established open source offline maps and navigation app - my hope for a privacy-friendly solution was reawaken. Hence, I investigated whether it was practically possible to use use this combination in a data-literate way. I stumbled over several caveats and irritating privacy-invasive issues but also found a semi-satifactionary workaround for the time being.

Targeted audience

If you are a person that has a stock Android smartphone with the preinstalled Google Apps and services running and is comfortable with this setup this article is NOT for you. On the other hand, if you use a custom Android Distribution such as LineageOS, GrapheneOS or Replicant or even a “true” Linux Mobile system such as postmarketOS, Mobian or Ubuntu Touch you are part of the targeted audience. Generally, I assume that readers of this article are data-literate, care about their privacy and want to effectively stay in control with whom they share which data.

Disclaimer

All data and information provided in this article is for informational purposes only. The author makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this article and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.

In no event, the author will be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this article.

Caveat #1: Google Apps (“gapps”) required

The first surprise for newcomers is that you can’t use Android Auto with a “free” Android distribution that was built from the components of the Android Open Source Project (“AOSP”) such as LineageOS, GrapheneOS or Replicant. Instead, Android Auto is part of the proprietary “gapps” framework and requires the installation of these proprietary components. This is sad since the major motivation for many users of “free” Android distributions is to avoid the installation of proprietary components.

The resulting practical consequence for a privacy-friendly setup is that a dedicated Android device solely for Android Auto needs to be used. While not ideal, plugging in a second device and using it for navigation via the headunit is still much more convenient than using an external device.

The additional Android device could be any stock Android device or a device running LineageOS plus “gapps”. However, unless you don’t already own a device with an outdated Android version that does not support Android Auto at all, I don’t see many benefits of such an setup. I rather find it legally and ethically problematic to install proprietary software from questionable sources on such a device.

Another noteworthy issue is that not only Android Auto’s implementation but even the protocol is not open. However, the protocol has been recently reverse-engineered by BlueWave Studio’s OpenAuto project [1].

Caveat #2: Additional “Playstore-only” apps required

In addition to the basic “gapps” framework, the installation of additional apps that are only available from the Google Play Store is required. These are:

Android Auto
Google App
Google Speech Services
Google Maps (what an irony…)

While “Google App” is already part of gapps, it will likely need to be updated to match the version of Android Auto. Unless you install all these apps before connecting your device with your car, the Android device will tell you that it can’t work with your car until these dependencies are satisfied. For privacy reasons, you better don’t want to ever go online with your Android device after your device was in touch with your car so better install these requirements beforehand.

So, the even bigger caveat here is that in order to use OsmAnd with Android Auto and need to have a Google Account to install these required apps.

And yes - in theory, you probably could also download these apps from “alternative” stores such as those that use the API of the Google’s Playstore to fetch the apk files using fake accounts. However, you will very likely violate Google’s terms and conditions and, in addition, you will eventually even commit a copyright infringement by doing so. See [2] for a more detailed discussion about using such stores.

Caveat #3: No hands-free phone calls while navigating

Maybe you already have a headunit in your car that allows you for hands-free calling using the built-in microphone and speakers over bluetooth? Unless you do not give permission to your smartphone for syncing your contacts list and calling history with the headunit in your car, such a solution might seem privacy-wise acceptable. Of course, you can never technically rule out that a head unit running proprietary software will not record the calling history or even your phone calls without your consent anyways. However, this would be certainly illegal in the EU and, hance, it depends on your personal level of paranoia whether you consider this a viable threat.

The more interesting question for me was whether you could navigate using OsmAnd via Android Auto and simultenously use hands-free calling to place or answer calls. The very bad news here is - you can’t - at least for the head unit I tried with! This is because Android Auto seems to use Bluetooth for Audio and assumes that you use the same device for calling as for phone calls. You need to first disconnect the additional (dedicated) Android Auto device in order to be able to use hands-free phone calls again.

Caveat #4: Tricky initial setup

In order to replicate my setup you need to do the following steps:

Get an Android device with gapps (I tested this using a device running Android 10 - be warned that Android 12 is known to have issues with OsmAnd and Android Auto at the time of writing).
Install adb on your computer.
Get access to the play store (create a Google Account).
Download the required apps mentioned in the section “Caveat #2”.
Optional: Unassociate the Google Account from your device and close the account.
Download the apk file for OsmAnd from the F-Droid store (from the F-Droid website directly, not using the F-Droid App!)
Enable developer mode and activate adb on your Android device
Install the OsmAnd app using the adb workaround described below (otherwise the OsmAnd icon will be missing in Android Auto and you won’t be able to use it!).
Start OsmAnd and download any maps and additional content (such as POIs) you require.
Disable wifi on your device (ideally with kill switches or another effective airgap method)

Due to an issue discussed in [3], the OsmAnd app needs to be installed using the following commands:

adb push net.osmand.plus_424.apk /data/local/tmp
adb shell pm install -i "com.android.vending" -r /data/local/tmp/net.osmand.plus_424.apk

Yes, this initial setup requires some work. But believe me that finding out what needs to be done here was even more work. ;-)

Caveat #5: Uncomfortable updates

So far so good for the initial setup. But what to do for updating maps or adding POIs without the risk of data leaks? Here are three suggestions:

download the updated content on another device (e. g. your main smartphone) and transfer the files manually over a wired connection (adb, rsync or friends)
setup a firewall that only allows connections to map and POI providers and download the content with the Android device sitting behind this firewall.
if you don’t update content frequently wipe the Android device and redo the initial setup (eventually in some scripted/automated way)

Please let me know if you have any better suggestions!

Conclusion and future perspectives

I find it highly irritating that car drivers are virtually forced into signing a contract with Google just to be able to use a car’s head unit via Android Auto for a 3rd party navigation app that does not need any Google service at all.

The described setup might seem like a messy and complicated workaround at first. Yet it is the best privacy-friendly solution I am aware of for the time being. I find this approach more convenient than attaching a second dedicated navigation system or using OsmAnd via some smartphone holder in the car instead of using the headunit which is actually there for this purpose.

Of course, the described setup has several drawbacks, the biggest one proabably being the bluetooth issue. To workaround the bluetooth issue, my recommendedation is to use the built-in hands-free calling when not navigating and to use an external bluetooth headset to cover the remaining situations.

I looked for better alternatives and found the AACS project by by Tomasz [4] that reimplements Android Auto for native Linux. AACS allows you to display the output of a Linux machine on the headunit and process input from the headunit’s touchscreen. I haven’t tested this approach yet but it sounds very promising. I hope true Linux Mobile apps will provide such a facility ootb in the near future. Even though I am not aware of any equivalent alternative to OsmAnd for Linux mobile systems yet, running OsmAnd via anbox using AACS instead of proprietary Android Auto client on a native Android device sounds like a great step in the right direction.