1. Android Framework Location API
It has 3 location providers:

1. NETWORK_PROVIDER
   
   • Calculates location using nearest cell towers and wifi access points.
     
   • Uses ACCESS_COARSE_LOCATION permission which allows the app to get only an approximated location.
     
   • It is fast and battery consumption is low.
     
   • Accuracy is not very good.
     
2. GPS_PROVIDER
   
   • Gets location values using satellites.
     
   • Uses ACCESS_FINE_LOCATION permission to provide a more precise/accurate location.
     
   • Gives high accuracy of current location.
     
   • Needs continuous power supply.
   • Might be slow sometimes.
     
3. PASSIVE_PROVIDER
   
   • Does not request location updates itself.
     
   • Passively receives location information from other applications that are using location services.
     
   • Not reliable because if no other app on the phone is getting location updates, our app won't get them either.
     
   • Accuracy is also very low.
     

The Google Play services location APIs are preferred over the Android framework location APIs (android.location) as a way of adding location awareness to your app. If you are currently using the Android framework location APIs, you are strongly encouraged to switch to the Google Play services location APIs as soon as possible.
…
The Google Location Services API, part of Google Play Services, provides a more powerful, high-level framework that automatically handles location providers, user movement, and location accuracy. It also handles location update scheduling based on power consumption parameters you provide. In most cases, you'll get better battery performance, as well as more appropriate accuracy, by using the Location Services API.

Whenever an application runs in the background using services, it consumes memory and battery which are very limited resources. So, Android O onwards, the application is allowed to create and run background services only for a few minutes after which they are killed by the system.

Some periodic task can be created using a scheduler that will start service again after some given interval, service will do its work and then stop itself again. By this, the application will not be considered battery draining. But there are some limitations in the number of times an app can request location update in background. Also the doze mode and app standby delays the execution by some amount of time if the phone is idle.

A foreground service will keep the user aware that application is performing some background tasks by displaying a persistent notification and the system will consider it to be something the user is actively aware of and thus not a candidate for killing when low on memory or power.

But as this notification couldn't be dismissed, users may find this behavior annoying.

Our solution:
We will be using a Foreground Service for Android versions O and above as it makes it possible to get uninterrupted continuous location updates which is very essential for this app.

Using a global broadcast, any other application can also send and receive broadcast messages to and from our application. This can be a serious security threat for the application. Also global broadcast is sent system-wide, so it is not performance efficient.

Android provides local broadcasts with the LocalBroadcastManager class which provides following benifits:

• Broadcast data won’t leave your app, so don’t need to worry about leaking private data.
• It is not possible for other applications to send these broadcasts to your app, so you don’t need to worry about having security holes they can exploit.
• It is more efficient than sending a global broadcast through the system.
• No overhead of system-wide broadcast.

Our solution:
We are using a BroadcastReceiver to receive the updated location in MainActivity that is going to be broadcast locally from the Service and then update the UI.

• Easy to understand and use
• Treats the Api calls as simple java method calls
• Handles the Json/Xml parsing itself
• We do not have too many custom requirements in terms of caching and request prioritization
• Good community support

Geofencing combines awareness of the user's current location with awareness of the user's proximity to locations that may be of interest. To mark a location of interest, you specify its latitude and longitude. To adjust the proximity for the location, you add a radius. The latitude, longitude, and radius define a geofence, creating a circular area, or fence, around the location of interest.

Points to consider:

• You can have multiple active geofences, with a limit of 100 per app, per device user.
• For best results, the minimium radius of the geofence should be set between 100 - 150 meters.
• When Wi-Fi is available location accuracy is usually between 20 - 50 meters. When indoor location is available, the accuracy range can be as small as 5 meters. Unless you know indoor location is available inside the geofence, assume that Wi-Fi location accuracy is about 50 meters. When Wi-Fi location isn't available (for example, rural areas) the location accuracy degrades further.
• If there is no reliable data connection, alerts might not be generated. This is because the geofence service depends on the network location provider which in turn requires a data connection.
• The geofence service doesn't continuously query for location, so expect some latency when receiving alerts. Usually the latency is less than 2 minutes, even less when the device has been moving. If Background Location Limits are in effect, the latency is about 2-3 minutes on average. If the device has been stationary for a significant period of time, the latency may increase (up to 6 minutes).

We should verify a user's identity before giving him access to the app.