However, for app developers, enhancements to the UI aimed to conserve battery life affect GPS services and require changes to the code in order to optimize pre-existing apps for the new OS. Specifically, Android Oreo restricts apps that are running in the background with limited access to background services. Additionally, apps can no longer use their manifests to register for most implicit broadcasts. When an app is in the background, it is given several minutes to create and use services, but at the end of that time slot, the app is considered idle and the OS will stop running background services.

These changes directly affect apps with geolocation functionality. Android Oreo limits how frequently apps can gather location in the background. Background apps can only receive location updates a few times each hour. The APIs affected due to these limits include Fused Location Provider, Geofencing, Location Manager, Wifi Manager, GNSS Measurements and GNSS Navigation Messages.

Apps that currently use location services in previous Android OS’s will require an update to optimize for Android Oreo. Apps that use location services range anywhere from navigational apps like Waze and Google Maps to social media apps like Twitter, and food apps like Yelp and Seamless.

For apps that require frequent location updates, increasing the usage of the app in the foreground will ensure that the app gets frequent access to location information. In order to program this, developers must implement startServiceinForeground() instead of startService() in Activity class.

In Service class in onStartCommand(), developers can use the following code:

When foreground services running in the background consume high energy, Oreo fires an automatic push notification to the user informing them of the battery-consuming service. With the push notification in place, app users are more likely to uninstall apps that track location without conserving battery life, putting the onus on software developers to deliver battery-efficient apps. One of the biggest issues facing some app developers is ensuring that battery life is not sucked as a result of tracking location in apps. Check out our full rundown of how to build battery-efficient geolocation apps for supplementary reading.

The results of the limits put in place with Android O are increased battery life for the user and the necessity for app owners to consider how their apps interact with location information. Retaining a thorough understanding of how location information will be retrieved and used through out the development process ultimately benefits both software developers and consumers with better UI and more energy efficient processes.

On March 21st, Google unveiled the developer preview for the latest version of the largest OS in the world: Android O. For consumers, it means improved UI, design, battery life, & more. For app developers, it has far deeper implications. With release anticipated in Q3 2017, here is our rundown of the top takeaways about Android O for Android developers:

BATTERY LIFE

The main focus of Android O appears to be to continue Android Nougat’s initiative to reduce battery life. The OS will limit and manage what launched apps can do in the background when multiple apps are open. For example, if a user has a geolocation app open in the background while using another app, location updates will happen less frequently for the background app.

In technical terms, background execution & location limits have been reigned in, allowing the OS to better manage background activity. Background apps are defined by Google as apps showing no visible activity, no foreground service & not connected to a foreground app through its services. Location changes affect the following APIs:

Fused Location Provider (FLP): The local system service computes a new location for background apps only a few times each hour, according to the interval defined in the Android O behavior change. Foreground apps will not experience location sampling rates in relation to Android 7.1.1 (API level 25).

Geofencing: Background apps can receive geofencing transition events more frequently than from FLP.

GNSS Measurements:Callbacks registered to receive outputs from GnssMeasurement and GnssNavigationMessage will stop executing for background apps.

Location Manager:Location updates will be provided to background apps only a few times per hour according to the interval defined in the Android O behavior change.

NOTIFICATION CHANNELS

Android OS’s have always thrived in the notification department. Android O allows developers to group notifications into channels. Developers must select a channel for each distinct type of notification they send with the goal of making things easier and more customizable for the user. For example, a user can turn off the “Sports” notification channel from the New York Times app if they are already getting sports notifications from the ESPN app.

Developers can also allow user behavior to dictate notification channels. For example, the developer of a messaging app can create separate notification channels for each of a user’s messaging threads.

WI-FI AWARE

Wi-Fi Aware, or Neighbor Awareness Network (NAN), allows devices to discover and connect directly with each other without any other connectivity between them, like Wi-Fi Access Point or Cellular. Two phones can connect with each other with NAN and share data at high speeds without any additional apps or configuration, opening up tons of possibilities for developers.

Learn more about Wi-Fi Aware:

HI-FI BLUETOOTH AUDIO

Android O supports Hi-Fi Bluetooth audio. While the quality of the audio still depends on the speaker or headphone through which one listens, this is a major improvement for music lovers.

ADAPTIVE ICONS

Android O will introduce adaptive launcher icons. Adaptive icons support visual effects and can display a variety of shapes across different device models. Adaptive icons are a major tool for developers to guide the user’s eye and enhance UX. Check out Android’s developer site to learn more.

The O Developer preview will run from March 21st to the final Android O public release anticipated in Q3 2017. Android will provide incremental updates in mid-May, June, & July. Until Q3 2017, the onus is on Android developers to prepare their future and existing apps for the latest operating system.

The ability for smartphones to offer location services fostered major opportunities for app developers looking to create new apps and enhance functionality of existing apps. Tinder, FourSquare, & Waze use geolocation in the center of their functionality to great success. In combination, these three apps can help a user determine a dinner companion, restaurant of choice, and route to the restaurant. By delivering location-sensitive information to users regardless of where they are in the country, these apps appeal to massive audiences.

Programming geolocation services into an app will have a major impact on the overall quality of the app—and it’s easier said than done. Inefficient geolocation services drain device battery life and deliver inaccurate location data. When apps drain battery life, users uninstall them. In order to determine the best method of programming geolocation services, it is vital for app developers to know who is going to be using the app and how they are going to use it.

Location can be determined by a smartphone in a number of ways. The most widespread include:

GPS: All modern iOS & Android smartphones are equipped with GPS technology. GPS can use at least four satellites to determine a user’s location within about 60 feet.

Cell ID: When GPS isn’t available, phones can use Cell ID, information from cellular towers, to determine location. Cell ID is ideal in big cities with vast amounts of cell towers. Serial fans should be familiar with how cellular tower information can be vital in identifying one’s location. GPS & Cell ID can also work in conjunction to deliver a more precise GPS location.

Wi-Fi: Devices can detect Wi-Fi networks in the same way they can detect cellular towers, but Wi-Fi is more precise as Wi-Fi networks cover smaller regions. Devices can use RSSI (Received Signal Strength Indication) to refer signals from the phone with Wi-Fi points database. Devices can also use the user’s frequently visited places, a profile or wireless fingerprint based on locations in Wi-Fi networks frequented by the user. Wi-Fi can identify a user’s position within 2 meters of accuracy.

The decision of how an app should prioritize these three methods to determine location is a vital one. If users are located in the city, that means both dense Wi-Fi router and cell tower coverage will open up options. If the app is being used primarily in a domestic situation, Wi-Fi might be both the most accurate and efficient method. Apps designed for rural areas may have to use Wi-Fi due to lack of cell towers.

Geofencing Graphic from Applidium

GEOFENCING

Geofencing utilizes a device’s GPS to determine a user’s distance from a particular point. Geofencing can sense when a user enters within a set radius defined by the coordinates of its center. Geofencing will sense when users are inside or outside of a retailer and offer action prompts for either space. There are three types of geofencing:

Static geofencing is based on a user’s position in relation to a specific place. For example, a retailer app sends a message to users who pull into the parking lot of a mall containing the retailer.

Dynamic geofencing takes into account both a user’s location and a changing data stream. For example, a parking app sends the user a message about a recently evacuated parking space that the user is approaching.

Combined geofencing determines when a user enters into a location in relation to other users. For example, apps like Yelp, Facebook, or FourSquare send notifications if a friend checks into a nearby merchant .

CREATING BATTERY-EFFICIENT APPLICATIONS

Making a geolocation app battery-efficient is one of the biggest challenges app developers face in the programming stage. Developers must create a comprehensive strategy based on their audience.

ACTION THRESHOLDS: Defining accurate action thresholds and use-cases for an app’s geolocation services will dictate its level of battery-efficiency. The more precise your location accuracy requirements, the greater the battery drain. Action thresholds and use-cases define how an app is intended to be used, allowing a framework for developers to enact an efficient model of internal processes for location determination.

COMPREHENSIVE TESTING: Testing the app aggressively to gather a large amount of data is the only way to know the most efficient action thresholds. The more the developer understands how an app is being used, the more they can refine their programming. After release, continuing to gather analytics from user behavior and refine tactics based on how users are getting value from the app becomes a crucial ongoing process.

POLLING FREQUENCY: One of the major variables dictated by action thresholds is polling frequency. The more an app polls for locations, the better its location accuracy. The necessary level of location accuracy varies depending on the app. The precision of location accuracy necessary for an app to be functional can vary. A restaurant app, for example, might be able to get away with accuracy from 200 meters to a few kilometers, while an app that locates friends might need accuracy within 10 – 20 meters.

Evaluating the most efficient polling frequency requires thorough use-cases and some creativity. Programmers can design algorithms to reduce polling frequency if an app hasn’t changed locations for several minutes. Programmers can also analyze the speed of the device and use this data to change polling frequencies. A developer may elect to increase polling frequency as a car accelerates to ensure they maintain location accuracy within a selected radius.

DEFERRING TO OS: Many major mobile platforms will share geolocation information at an operating system level. As a result, any app that is listening can receive location updates requested by other apps. By deferring to other apps already polling for location data, apps can minimize battery drain while still retaining acceptable location data.

Check out Apple and Android’s developers’ sites for more information on best practices for programming location services.