google play store monitor the bad behavior of Excessive Wi-Fi Scanning in the Background.
not able to identify the issue
i have add bellow permission in manifest
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
please suggest appropriate response.
thanks
Assuming your app is using FusedLocationProvider. If you subscribe to retrieve location from GooglePlayServices in background more often than once per 15 minutes, your app will be blamed for excessive WiFi scanning.
https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.html
Activities should strongly consider removing all location request when
entering the background (for example at onPause()), or at least swap
the request to a larger interval and lower quality.
If device is setup in high accuracy location mode, the device will attempt to use wifi scans in order to resolve its location. Hence you have to consider increasing active interval for retrieving location updates.
public LocationRequest setInterval (long millis)
Excessive Wi-Fi Scanning in the Background occur, Android vitals considers Wi-Fi scanning excessive when an app performs more than 4 scans per hour. Normally this issue can be reported by Android vital via play console. Otherwise we can use Battery historian tool to find background wifi scanning for each application.
We rectify this problem
If possible, your app should be performing Wi-Fi scans while the app is running in the foreground. Foreground services automatically present notifications; performing Wi-Fi scans in the foreground thus makes the user aware of the why and when Wi-Fi scans take place on their device.
Related
I have a security system where moving a Bluetooth LE device causes my android application to do some work. After some of the newer Android updates, I believe API 26, I could no longer get these updates if the Android device's screen was off. I was trying to think of a way around this and came up with an idea:
What if I paired the Android device and the Bluetooth device - would this allow for the message to be received when the Android screen is off?
Previously, all my BLE devices were part of a mesh, so I would regularly have the Android app check for changes in the mesh and turn the screen on to notify the user if needed. Now, because of the background execution limits introduced, I must require the Android device to have the screen on at all times, which leads to the death of display over time.
I'm not that great at programming in C, which is the language the BLE chips are programmed in, so I wanted to ask this first before spending hours just to see this NOT work. So, just to repeat the question: Will having a BLE device paired with the Android device allow a message through these restrictions when the Android screen is off?
If not - is there a way I can make this work?
Thank you for any info!
Use notifications instead of advertisements. This will deliver data instantly and works even if the screen is off. Newer versions of Android have introduced more restrictions for BLE scanning when the screen is off.
Use connectGatt with autoConnect set to true to automatically connect and reconnect in case the connection drops.
Use a Foreground Service in your app process to prevent the app process from being killed. If your app process exits, all Bluetooth connections are dropped as well.
You could use CompanionDeviceManager to gain some extra permissions.
You don't really need to be paired but it has some benefits such as faster connection setup and correctly remembering the address type (flaw in the API that this is missing).
This is more of a general question, but to what extent can we use the Nearby Connections API in services?
I noticed that discovery and pairing is still working while the app is out of focus, so is it possible to extract the whole connections client into a foreground- or even a background service which is running while the app itself doesn't have to?
There are no restrictions on using Nearby Connections from a service. However, Android has always somewhat aggressively killed background services (and is more aggressive since Android Oreo). There's also no way to limit the power, so advertising, scanning, and maintaining a connection for a long period of time will adversely effect battery life. There's a plan to expose a low power flag, but there's no ETA.
Disclaimer: I work on Nearby Connections
On devices running Android Q or higher, an ACCESS_FINE_LOCATION permission has to be requested to use Nearby Connections. When an app runs a background service, like a JobService, using Nearby Connections on a device running Android Q or higher, the app will not be able to discover nor to advertise, unless the ACCESS_BACKGROUND_LOCATION permission has been granted to the app by Google. To get it granted by Google, you have to explain in detail why your app needs it, and there is no guarantee that you will get it. This said, on Android versions lower that Q, an app can successfully discover and advertise in a background service, as long as it has requested all the nedded permissions (BLUETOOTH, BLUETOOTH_ADMIN, ACCESS_WIFI_STATE, CHANGE_WIFI_STATE and ACCESS_COARSE_LOCATION).
I'm working on an Android app that needs to detect if other users of the app are close to each other (lets say within the same room or Bluetooth range). The app needs to be able to detect this without any user interaction.
Geolocation is not an option as this is too inaccurate indoors.
The app runs only on company owned phones that stay on company ground, privacy is not a concern.
All devices are always connected to the same wifi network and BT is always enabled.
My idea is to detect if users are within a close distance of eachother by periodically Bluetooth scanning and checking the results against a list of MAC adresses that contain all the devices that have the app installed.
The MAC adresses of all devices are send to a server, the devices then grab this list of mac adresses from the server to compare to the results of a BT scan.
Problem is, BT and Google's seem to use Advertisement / Discovery patterns where one device acts as the server and one device acts as the client. For this to work properly i feel like the devices need to always be discoverable.
Will an implementation based on Google's Nearby or BT work for my needs ?
Is it possible to detect the presence of a nearby device without it being discoverable ?
As battery life is a concern (need to be able to do this for atleast 8 hours a day) is BLE an option?
You can almost certainly handle 8 hours a day if the phones aren't really used for much else. There are a lot of variables, however.
Many older phones require a different type of scanning using infinite scanner restarts in order to properly report "seeing" a peripheral. This can dramatically decrease battery life.
If the phones are running Marshmallow or later, they have a doze mode which interrupts scanning. This can be circumvented using an AlarmManager, JobService/Dispatcher, or WorkManager. This can dramatically decrease battery life.
If the phones are running Oreo or later, they require a foreground service (persistent notification) in order to prevent the app from being automatically killed by the OS to save battery. The app should also be whitelisted from battery optimization because even with the foreground service, the app will still be killed off by the OS.
Finally, scanning and broadcasting and using location services is pretty expensive battery-wise. If you're attempting to cluster phones and guess their position based upon what other phones are nearby, at some level you'll still need the location data off of the phones to figure out where they're at.
You're much better off just scanning. You could carpet your company property with beacons, where each individual beacon's location is recorded. When the phone "enters a region" (comes within range of a beacon), it should send something to your api reporting which beacon it just found. This will tell you what room/area it's in.
Another less flashy (and potentially less accurate) way to track everything would be via the IP addresses of the wireless access points they're connected to. Use a WorkManager to periodically update an api with some unique ID for the phone and the IP address of the AP. Your IT department should know the locations of each of them. This way you get reasonably good tracking and virtually no battery drain.
We have a device that need to be started at night, the device is started thanks to a bluetooth command sent by a mobile application. It's possible to send this command while the app is in the background and keep monitoring the device (i.e. receiving data), for example, for 30 minutes?
If it's possible what would be the ways to implement this feature in iOS and Android?
Update: Think about a sleep tracking device; the problem shouldn't be to scan all night because the user must connect the device before go to bed (and eventually try to automatically reconnect to a known device, without the need to scan). I'm asking if it's possible to stay connected and send/receive data while, for example, updating an internal database all night.
Several thing to take into account about Android BLE system development, read this for more information: https://blog.classycode.com/undocumented-android-7-ble-behavior-changes-d1a9bd87d983
BLE Scanning has an abuse prevention since Android 7. What does this means?
Prevention for an app stopping and starting BLE scans more than 5
times in a window of 30 seconds.
Long-running scans are converted into opportunistic scans. (30 minutes).
About the background process depends on what type of service you want. You can start a foreground service with a notification or you can start a Job which runs always in the background with no notification.
If you can be more precise on how the system is going to work I can give a more detailed explanation.
How often does Android system scan Wi-Fi?
In following 2 cases:
When device is connected to a network
or
When device is not connected to any network.
Is it different from android OS version?
Is there any one know about that information?
How often does Android system scan Wi-Fi?
It depends on the application implementation and on the Android OS version (so yes is the answer to your second question).
Let's go more in the details:
you can use an instance of WifiManager to start your wifi scan by startScan() method. Thats could allow you to start all the scans you want, draining battery very fast.
Is for this reason that from Android 8.0 (API 26) there are restrictions on scan frequency.
The following limitations apply to the frequency of scans using
WifiManager.startScan().
Android 8.0 and Android 8.1:
Each background app can scan one time in a 30-minute period.
Android 9 and later:
Each foreground app can scan four times in a 2-minute period. This
allows for a burst of scans in a short time.
All background apps combined can scan one time in a 30-minute period.
REFERENCES:
Android system scans wifi :
1. If device has wifi enabled and device is not connected to any network, it scans for available network
2. If device is connected to network then system will scan available network on request from user (i.e. when user clicks scan button)
WiFi scanning is essentially dependent on the hardware manufacturer - along with maybe some user settings and other apps that are running (other apps may request scans for WiFi networks). So there really isn't a "standard scan time" for WiFi.
Here is a good reference that talks about the interval between WiFI scans (essentially saying that you should check with the user to see if they want a "scan as often as possible" option, or something else...)
What interval should I use between each WiFi scan on Android?
Unless your app is for developers, you should probably use a decaying algorithm, like check at 5 seconds, then 10, 20, 40, 80, 160... etc. until you max out at an acceptable timeframe (like 5 minutes - 300 seconds; or 1 hour - 3600 seconds). Then also monitor other events like phone sleep/wake or app launch. Use those to do WiFi polling - and try to connect and restart the decaying algorithm approach.
From my experiments on a LG G2 (Android 5.0.2), the wifi is scanned in the following situations :
when the Location feature is disabled
every time waking up from sleep mode
when activating the wifi (either manually or programmatically)
about every 2 minutes when wifi is enabled but the device is not connected to a wifi network
when the Location feature is enabled : it depends on applications that registered to locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, minTime, ...). When specifying a minTime of 0 ms, the network scan is done every 20 seconds.
The App "Wifi Scan Interval" reveals that minimum/maximum/average wifi scan frequency greatly varies with the phone manufacturer and model. But it could be because of the installed applications. Based on that, I would guess that the rules above may be different for other phones.