Background location service android

Android Background Geolocation Service Without Any Kill | Part 1

Android location services are very popular these days, they provide the location of a device in the form of latitude and longitude coordinates using with we can track the location up to 10 meters of accuracy. Location services provide many other parameters of a device like speed, the direction of movement, human-readable address using Geocoder service.

Google Android’s location services can also be used to track real-time, we can get real-time coordinates of device, speed, address, accuracy etc, this makes it possible to create tracking application for an example Uber and OLA uses these to track nearby cars, food delivery services to track your food.

But what if we want to track a device even if an application is closed or killed? Is it possible to track such device? Yes! its possible today’s we will create an Android Native application using location services which can track location even if the application is not open or closed intentionally, and even killed by a user.

Let’s get started!

Here we will start with a new Android project having Empty Activity

Here we will also add a Broadcast Receiver “LocationUpdatesBroadcastReceiver”. This BR will communicate with device’s Location Service through a Pending Intent which we will create in coming steps.

So our AndroidManifest.xml will finally look like this

In build.gradle(Module:app) file will add Google play services required to use location services, XDroid’s toaster(optional, but I am using this third-party package to show toasts) and Android’s design package v 27.1.1 to show Snackbars.

Here we need to change the default value of minSdkVersion to 16 from 15, as 15 SDK doesn’t support notification expand for big text.

Let’s move to MainActivity.java, here we will do many things:

First, when the application initializes or onCreate method is called, we will check if the device is having proper permissions? If not we will show a permission acceptance box to accept, otherwise a Snackbar will show up continuously to enable location permission.

FusedLocationProviderClient is getting access from Google API to use Location services, We use Fused Location Client after 11.0.1 version of Google Play services. This is more stable and healthy in terms of Device resource management and battery conservation.

Using LocationRequest, for setting the preference to fetch Device coordinates:

setInterval: Gap between location updates.
setFastestInterval: Shortest gap possible for real-time updates.
setPriority: Choose from available options, in terms of battery consumption and accuracy of device location.
setSmallestDisplacement: Distance in feet only after which next update will be available.
setMaxWaitTime: Maximum time before wich update must be sent.

You can read more about these on official documentation by Google

PendingIntent will be given to a Broadcast Receiver which in turn will look for location updates. We can simply start and stop out a PendingIntent look using Broadcast Receiver. This will play a key roll in keeping our Location Service in Background alive.

Why not a Service instead of Broadcast Receiver?

We can do that using a service but in future Android API’s we will have limited slots from Service Threads available due to betterment in resource management.

We also have two buttons START TRACKING and STOP TRACKING and a text to show Location and Address in application’s Main Activity.

So our final MainActivity.java is follows

Create a new class Utils.java under root package, this class will have getLocationUpdates which will be called from Location Broadcast Receiver to get device details like Lattitude, Longitude, Speed, Direction, Accuracy etc.

On getting called getLocationUpdate method will pass on all values to a method showNotificationOngoing which will show custom notification real-time with information like time and address related to lattitude and longitude coordinates recieved. These notifications will be frozen type and can’t be removed by swiping, as we have set .setOngoing(true) to true

We also have removeNotification method to remove notification when location service is intentionally stopped by the user.

Use of Geocoder Service

We have also used Geocoder Service by Google to convert Lattitude and Longitude in a human-readable address. This makes it more convenient from the user point of view.

The getAddress method is converting an array of location address into comma separated string which we will show in Notification and In application.

final Utils.java file will look like this.

Find source code in part 2 of this tutorial here

Источник

Android Location Tracking In Background Service

In this tutorial i’m going to explain about how to track the location of the device using a background service with Google LocationServices API Client and share the location to the Activity using a broadcast receiver. The background service will keep running as long as the application exists in the memory and sticks to the notification drawer. The service handles the following functionalities,

• Connecting to Google LocationServices API
• Getting the current location
• Sharing the result to the Activity

Step 1: Add Dependencies To build.gradle

Please add the below mentioned dependencies to your module level build.gradle file.
The most important dependency here is the com.google.android.gms:play-services-location:11.0.4 .

Step 2: Create Location Monitor Service

For this, first create a service class called LocationMonitoringService under services package. We have implemented the Google API connection and the callbacks here. This service class will take care of all the location motoring related functionalities.

Step 3: Add Permissions And Service In Manifest File

We need Internet permission to call the Google API, ACCESS_NETWORK_STATE for knowing the state of internet connection of the device and Location permissions i.e, ACCESS_FINE_LOCATION , ACCESS_COARSE_LOCATION .

Step 4: Create Activity And Start Service

This is the activity from where we start the Location monitor service and it will be killed when you kill the activity. The service will start getting location changed callbacks and it will return the result to this Activity. The activity will access the result through a BroadcastReceiver and set it to the TextView in the UI.

Before starting the service we have to make sure that some prerequisites are there. We are splitting the entire activity functionalities into 3 STEPS for better understanding the flow.

The mentioned 3 steps are as follows,

• Check Google playservice is installed
• Check User has an active internet connection.
• Start the service.

Источник

Background location service android

Web Development Mean Stack, Laravel, WordPress

Game Development Unity 2D/3D

UI/UX HTML5/CSS3, Bootstrap

Mobile App Development iOS, Android

Blockchain Development Hyperledger, Steem, Corda, Ethereum

AR/VR Development HTC Vive, Oculus

Artificial Intelligence Machine Learning, Deep Learning, Voice based Solutions

We are

Background Location usage in Android 11

Written By, Savan Kashiyani

Overview

Restricted location permission in Android R

Source: Dribble by Somy Dhyani

Developers often get confused with ever-changing location usage policy, let’s clear that fog in this blog.

Topics

Changelog

Google has been working on user’s privacy for the last few years, as a part of security and privacy they restricted location usage in android applications. Let’s take a look at changelog in android versions for location usage.
Android 8 (Oreo): Apps accessing location in background will receive location updates a few times each hour.
Android 10 (Q): New ACCESS_BACKGROUND_LOCATION permission for the apps using location in background, prior to this version there was a single permission for background and foreground state of application.
Android 11 (R): ACCESS_BACKGROUND_LOCATION is separated from other location permissions, the user has to grant background permission explicitly from the application’s setting page. Developers have to design custom consent dialog for this permission and redirect users to the application’s setting page to grant the permission. Another major change is foreground location service, apps must display a notification indicating ongoing location activity in service, check out “while-in-use restriction” section for implementation.
Let’s take a look at code snippets to better understand how to prompt users for the location permission:

Источник

Подготовка приложения к Android Q. Часть 1

Перевод статьи подготовлен специально для студентов курса «Android-разработчик. Базовый курс». Также напоминаем о том, что мы продолжаем набор на расширенный курс «Специализация Android-разработчик»

Мы находимся на 10-м году разработки Android (Android Q должен быть версией 10.0). В соответствии с Beta 4, официально у Android Q 29-й уровень API. Несмотря на то, что уже есть Beta 5 и ожидается Beta 6, API был помечен как окончательный, и сейчас самое время посмотреть, как Android Q повлияет на приложения и какие изменения нужно внести, чтобы полностью поддерживать Android Q.

Важные изменения (не все), представленные в Android Q, можно разделить на две категории: а) Конфиденциальность и безопасность, б) User Experience.

От переводчика: «Мы разделили перевод на две части соответствующие данным категориям. Соответственно в первой части поговорим о конфиденциальности и безопасности».

1) Конфиденциальность и безопасность

а) Запуск фоновых Activity

Больше нельзя запустить Activity, когда ваше приложение находится в фоновом режиме.

• На что влияет: Все приложения, работающие на Q (независимо от целевого SDK). Генерируется исключение, если Android Q — целевая версия приложения; и Activity просто не запустится, если Android Q — не целевая версия SDK для приложения, но оно работает на устройстве с Android Q.
• Исключения: Привязанные службы, такие как специальные возможности, автозаполнение и т. д. Если приложение получает PendingIntent от системы, мы можем использовать его для запуска Activity. Если у приложения есть разрешение SYSTEM_ALERT_WINDOW (удалено в Android GO) или приложение недавно вызывало finish() для Activity (не рекомендуется на это полагаться. «Недавно» может быть очень неоднозначным), тогда ваше приложение свободно от этого ограничения.
• Рекомендуемый подход: Уведомление, запускающее Activity

Добавьте Fullscreen PendingIntent к уведомлению. Теперь, когда уведомление сработает, система запустит полноэкранный Intent.

Поэтому, если мы хотим запустить Activity из фонового режима, сначала создайте уведомление, которое будет показываться пользователю. В этом уведомлении добавьте Fullscreen PendingIntent . Кроме того, добавьте разрешение USE_FULL_SCREEN_INTENT в свой манифест. Теперь, когда уведомление сработает, система запустит полноэкранный Intent.

• Подводные камни: Система решает, когда показывать уведомление и когда показывать Activity. Если пользователь активно использует устройство, то отображается всплывающее уведомление. Если устройство в состоянии покоя или когда пользователь взаимодействует с уведомлением, запускается полноэкранное Activity. Например, как при получении телефонного звонка (всплывающие уведомления во время использования телефона, в противном случае полноэкранное Activity).

б) Аппаратные идентификаторы

Доступ к несбрасываемым идентификаторам устройства был отменен в Android Q.

• На что влияет: Все приложения, работающие на Q (независимо от целевого SDK). Генерируется исключение, если Q — это целевое SDK; и возвращается null , если целевое SDK меньше Q
• Избегайте: Mac-адрес теперь рандомизирован, а IMEI ( TelephonyManager.getDeviceId() ) и серийный номер больше не доступны. Теперь они являются «привилегированными разрешениями» и доступны только для приложений операторов.
• Рекомендуемый подход: используйте сбрасываемые идентификаторы, такие как Advertising ID, Instance ID или Globally-unique ID (GUID). См. Best practices for unique identifiers (Лучшие практики по использованию уникальных идентификаторов) для получения дополнительной информации о том, какой идентификатор использовать в каком случае.

в) Фоновое определение локации

Начиная с Android Q, система будет различать запросы местоположения, сделанные на переднем плане и в фоне.

Запрос на разрешение доступа к местоположению теперь будет иметь 3 варианта: Разрешать все время, Разрешать только при использовании приложения (доступ только на переднем плане) и Запретить (нет доступа).

• На что влияет: Это зависит от целевого SDK. Если Q — это целевое SDK для приложения, то вам нужно запросить новое разрешение на определение местоположения в фоновом режиме. Если у приложения другое целевое SDK, оно автоматически получит это разрешение, если уже имело права доступа к местоположению.

Изображение взято из документации для разработчиков Android

• Рекомендуемый подход: если приложению требуется однократный доступ к местоположению пользователя для выполнения некоторых задач, используйте службу переднего плана с параметром foregroundServiceType, заданным как location в файле манифеста приложения.

Если приложению необходим постоянный доступ к местоположению устройства, например, для геозонирования, то оно может настроить запрос на разрешение доступа к местоположению в фоновом режиме. Другие аспекты приложения (например, как местоположение извлекается аи используется) менять не нужно. Чтобы запросить доступ к местоположению в фоновом режиме, добавьте в манифест разрешение ACCESS_BACKGROUND_LOCATION :

Запрос доступа к местоположению в фоновом режиме

Напоминание, показываемое системой, о доступе к местоположению в фоновом режиме

Несколько важных вещей, о которых следует помнить: пользователь может получить напоминание после предоставления приложению доступа к местоположению устройства в фоновом режиме, и, как и любое другое разрешение, пользователь может отозвать разрешение на него. Это особенно важно для приложений, у которых Q не является целевым SDK, но работающих на устройствах с Android Q, поскольку оно получило бы фоновое разрешение по умолчанию, если бы у него было разрешение на определение местоположения. Убедитесь, что приложение изящно обрабатывает такие сценарии. По этой причине всякий раз, когда приложение запускает службу или запрашивает местоположение, проверьте, позволяет ли пользователь по-прежнему получать приложению доступ к информации о местоположении.

На этом первая часть статьи подошла к концу.А о User Experiences, как и обещали, поговорим во второй части.

Источник