Published on 12/15/2014 14:25 by Ritz

One of the fundamental difficulties of working in the mobile ecosystem is that, unlike the PC ecosystem, there is not a strong history of catering to a consumer’s desire for customization. The long history of “feature phones” that predates the modern smartphone has fixed mobile carriers in the mindset of providing a packaged solution to their customer base, rather than a platform on which to build a portable digital lifestyle.

The practical upshot of this is that the entire conversation around mobile is steeped in “vendor-think”, where consumers consider a particular phone to come complete with a framework which cannot be replaced or altered, and which is the only framework to which they have access. In almost all cases, these frameworks “phone home” constantly. A very well known case was the debacle in 2013 where researcher Ben Lincoln discovered that Motorola phones were sending exceptionally private user data on an unencrypted channel over the internet. Mobile operators and OS developers have a terrible history of both snarfing user data and metrics and being seemingly unconcerned with the security risks of doing so.

We have a name for software like this on a PC. We call it spyware.

Partial community solutions to vendor problems

On closed-source platforms, there is of course no work-around to this problem. If you’re surrendering the software you use entirely to the vendor, you have to trust them to treat your data with care. This trust has been pretty much blown over the last 5 years or so. Android has the distinct advantage of being a mostly open source platform (barring device modem firmware, which is something we can’t get around for now) that is also exceedingly popular and has a rich ecosystem. For that reason it’s become the phone OS of choice among the bulk of FOSS aficianados.

However, most manufacturer or carrier supplied Android flavors come replete with spyware, furnished by Google, the carrier, and often the manufacturer as well. For some, this is the justification to using an AOSP (Android open source project) based open source OS, in order to do away with carrier and manufacturer spyware. However, in many cases, users still feel compelled to install (along with their shiny new open source OS) the privacy compromising Google frameworks (often bundled as a gapps flashable zip).

The reason why people do this is obvious. The Google play store, along with Google location services and Google account support, provide a slew of tempting reasons to re-incorporate spyware onto your device. While f-droid provides an excellent (and always getting better) alternative to the play store, working around the maps and location services dependencies can be trickier.

Community solutions to community problems

In mid 2012 developer mar-v-in released the first version of something he referred to as the NOGAPPS project. It’s purpose, in the long run, was to replace the the bundled Google framework with something that was at the very least nonfunctional as spyware and hopefully retained some of the functionality of the original. As of this writing only two parts of it (the Network Location Service and Maps API) are functioning. The fake Play Store (called BlankStore) has been discontinued. mar-v-in has also continued his work (within the above linked github repository) to also de-spy-ify the popular Cyanogenmod android flavor.

mar-v-in originally released the NOGAPPS project on popular phone modding site xdadevelopers. It still, in my opinion, has not gotten as much fanfare as it deserves, despite 96 pages of a thread still active to this date. While I would definitely classify the project as being “alpha-beta” quality, it serves its purposes well enough in many cases. As always with projects like this, more developers are sorely needed.

Running without GAPPS

Although my personal experience thus far with NOGAPPS has been flawless, it has something to do with the fact that I’ve been modding my Android devices since I got the ADP 1 (the very first dev phone that Google made). The process of getting NOGAPPS running, even for custom OS users, can be a little daunting.

You can find the originals at their xdadevelopers thread.

Installing the network location service

1. Rename cells-northa.db to cells.db
2. Place cells.db in /sdcard/.nogapps/cells.db . You will probably have to create the .nogapps folder. More than likely the /sdcard directory is a symlink on your system to /storage/sdcard0, but it’s worth accessing it through the symlink to make sure you are in the right place when you place your cell location database.
3. If necessary (if you downloaded the Android 4.4 version) rename your NetworkLocation-gms.apk to NetworkLocation.apk
4. Move your NetworkLocation.apk to either /system/app/NetworkLocation.apk (if you are on Android 4.3) or /system/priv-app/NetworkLocation.apk (if you are on Android 4.4).
5. Change the permissions and ownership of the file to match all of the other files in the folder. This is important, and not mentioned in the original instructions.
6. Reboot the phone into recovery and wipe the dalvik cache. I repeat, wipe the dalvik-cache and not your regular cache. Then reboot the system (using your recovery’s “reboot system” option). This should take a while, as the system needs to rebuild the dalvik cache. 5 minutes is normal. Mine shows a progress window while this is happening.

You should now be able to enable network location services (High Accuracy and Battery Saver modes) without having installed the Google apps framework or even dialing out for location data, as you now have a locally hosted copy of the cell location DB.

Installing the flashable maps zip

If you’ve ever installed a custom android OS, the flashable Maps zip is a lot easier than the network location API

1. Reboot into your system’s recovery loader.
2. (Optional) wipe your dalvik cache. You can do this together with the above process. As far as I can tell it is not necessary to wipe anything else to get this to work.
3. Use your recovery loader’s zip installation functionality to flash the zip. it will likely happen so fast that you might think it didn’t work. Check the onscreen log. If it looks like it worked, reboot the system using your recovery’s “reboot system” option.
4. If it worked correctly, there should be a couple of new files on your phone. You should be able to find both /system/framework/com.google.android.maps.jar and also /system/etc/permissions/com.google.android.maps.xml . They should also have appropriate permissions.

With this fake maps API installed, you should have much less trouble with apps throwing fits because it isn’t present.

While this post was overly long, it was by no means exhaustive, and I can’t claim that this will work for everybody, or that it might even break your phone somehow. However that’s a risk familiar to everybody in the modding community. I can only hope that this post will help somebody else avoid having to install the hated Google framework.

Feel free to drop me a line if you want some help!

Ritz

Written by Ritz