Location without Google Services

Todor Kostov — Thu, 06 Oct 2022 16:11:14 +0000

These days you will rarely find an app that doesn’t have some kind of location-based functionality. Things like navigation, geofencing or location tracking are more and more common. It’s all good when you can rely on Google Play Services. Sadly, that’s not always the case. Sometimes the devices that your users are going to use don’t have Play Services installed. Such devices can be manufactured by some weird and unknown company, can have a custom ROM installed on them, or be located in a country where Google is not allowed to operate. No matter the reason, the fact that Google Play Services are missing from the device can make the task of obtaining the user’s location quit challenging. So let’s try to find out what options we have to solve this problem.

There are two different ways of obtaining a location without using Google Play Services:

By using the Location Manager
By using a 3rd party Network Location Provider (NLP)

Location Manager

This is the old school way of obtaining a location. By using the Location Manager we can choose between four different providers:

GPS - a precise way to determine the current location of the user. Although there are some drawbacks. This method is a bit slow and is not suitable for indoors use. The reason is that an actual connection with at least three GPS satellites must be established. The process is called triangulation. https://en.wikipedia.org/wiki/Global_Positioning_System
Network - that’s faster than using the GPS provider. It relies on using data about your current Wi-Fi or mobile network. It’s not that accurate compared to the GPS provider, but it’s faster and can be used indoors as well. It’s an interesting process, and it was developed long before the invention of GPS. You can read more here https://en.wikipedia.org/wiki/Mobile_phone_tracking
Passive - by using it we will get a location only if some other app had requested it. It’s power efficient, but it’s not reliable at all. Fused (since API 31) - it’s a combination between the other providers.

You can find a simple gist with examples here - https://gist.github.com/kostovtd/9bbe9352c7ef6adfc313bac193b48424

The good thing about using the Location Manager is that it is so old that it actually doesn’t use the Google Play Services under the hood. 😆

3rd party Network Location Providers (NLPs)

These Network Location Providers work somehow in a similar fashion like the Location Manager’s Network provider. The difference is that the phone sends a HTTP request with some data regarding cell tower coverage, IP address, etc. Based on this information, the corresponding service executes a search in it’s database and hopefully figures out your current location.

There are multiple services out there which provide a variety of different price packages, response formats and have different limitations. These are just three suggestions:

https://github.com/microg/UnifiedNlp - acts as a middle ware for multiple backends which have network location features.
https://ichnaea.readthedocs.io/en/latest/index.html - a geolocation service that uses both Bluetooth, WiFi and Cell data. The project is open only for not commercial use.
https://aws.amazon.com/location/ - provides a huge set of maps and location based features. Although, I was not able to find a simple way of getting the current location of the user.

Feel free to share, comment & give your opinion on the topic!

Lifecycle changes after API 28

Todor Kostov — Sat, 27 Aug 2022 12:41:01 +0000

Some time ago, I was going through the documentation about the infamous Activity class. All was good and even uneventful until I came across an interesting paragraph stating the following:

A question popped up in my head- but why the change in the order?

My first idea was to search for any articles on the topic. Sadly, with no result.

Then, I decided to go through the source code of the Activity class. There was also nothing that could provide some insight on the topic.

My last resort was to search for some discussions on Stack Overflow. To my surprise, there was a useful reference to the Android documentation.

Although the last paragraph throws some light on the topic, I was still not satisfied with it.

After initiating a discussion on Stack Overflow, I can conclude the following - First of all, it’s hard to come up with a precise answer to this question without actually involving some engineers from Google. For sure, they will be able to give enough information on the topic. Thus, the following statement is just speculation. The one possible reason behind this change is consistency. Before API 28, we couldn’t be 100% sure that the code in on Save Instance State will be executed at all. That can lead to losing important data and the inability to properly recreate the state. With the changes introduced in API 28, we can now be sure that our data will be saved.

Thanks to Martin Marconcini for giving his 5 cents on the topic.

Feel free to share, comment & give your opinion on the topic!

DEV Community: Todor Kostov

Location without Google Services

Location Manager

3rd party Network Location Providers (NLPs)

Lifecycle changes after API 28