background service is used to scan Beacon? - android

I can scan the Beacon in foreground using beaconManager.startScan(); so it is giving the beacons info available in the area.
same code I am using in service to scan the beacon and there also I am getting the beacon info.
But for scanning the beacon in background, I have to start the service.So is it the right practice to scan beacon using service.?

The topic of doing Bluetooth scanning in the background on Android is quite… interesting/complicated these days…
Using a background service isn't really a good option anymore. Starting with API 26 (Android 8.0), background services only continue running for a few more minutes once the user leaves the app.
(Arguably, it's not even a good option on older Androids. At Estimote, we found that some big-name Android smartphone manufacturers include their own power-management "optimizations" in their customized versions of Android, that tend to kill background services.)
You can use a foreground service, which has no limitations, but requires you to show a notification to inform the user that your app is still doing some work.
Finally, the good news is, in Android 8.0 there's a new API for Bluetooth scanning, where the BLE scan results get delivered via a PendingIntent rather than a standard callback. This will work even if the app got suspended/terminated in the meantime.
startScan(List<ScanFilter> f, ScanSettings s, PendingIntent i)
The bad news is of course, since this is API 26 (Android 8.0) and higher, you can't really rely on it much yet, as the Android 8 adoption is still very low. The future for background BLE scanning on Android looks bright, it's just not quite here yet.
--
Naturally, if you're using a ready-made scanning lib, it's best to consult with its authors about its background capabilities and how to use them.
The https://github.com/ufobeacons/Android-SDK lib seems (at a first glance at least) not to have any background support of its own, so you're probably best off just wrapping it in a foreground service.

Related

What is the exact purpose of the Android Notification Category? Specifically CATEGORY_WORKOUT?

Android Api level 31 introduces 2 new Categories CATEGORY_WORKOUT, CATEGORY_STOPWATCH. I tried to find a detailed information about those but nothing detailed is documented.
https://developer.android.com/reference/android/app/Notification
Is there any advantage of using those for a workout or stopwatch application? earlier I was using Category Progress which is claimed to keep as long running task. I suppose that Android gives it priority.
These categories are for ongoing notifications either on your phone or on a WearOS device.
The category will help the OS prioritize the importance of the notification.
There is an example of the usage in this Edge Wear OS ongoing activity walkthrough: https://developer.android.com/codelabs/ongoing-activity

Why the service doesn't start

I'm starting to develop for android, and I'm having an issue about services. I did a lot of research about this, but couldn't find a solution.
I'm doing an app that collects RFID tags information. For that, I'm using a third-party middleware that handles the bluetooth connection to the RFID reader and other events (like connecting, reading, errors etc). So, my app creates a broadcast receiver that handles all the message and data intents sent by the middleware. For this part, everything's fine.
The problem is that I'm trying to start middleware service using the code below (provided by the middleware documentation), but it doesn't work.
Intent intent = new Intent("com.supplier.middleware.runner");
intent.setPackage("com.supplier.middleware");
startService(intent);
I'm currently using an Asus Zenfone MAX M1 (ASUS_X00HD) with Android 8.1.0. The documentation also describes a way to stop the service (which I must use when I close the app), and the stop service intent works. So, if I start the middleware manually and try to close programatically, it works fine.
After some days trying - unsuccessfully - to solve this, I tested my app with a Motorola Moto Maxx (which is Android 6, I think) and with a Samsung J1 (which is Android 5.1.1) and both smartphones worked fine: when I call the startService, a notification item appears; when I call stopService, the notification item goes away.
I also tried to use "startForegroundService" because of the Android 8, but no success either.
Is there a way to "monitor" the startService calls, so maybe I could track any error? Am I doing something wrong - or rather, am I not doing something that is important?
In Android 8.0 background service limitation.
https://developer.android.com/about/versions/oreo/background.html
You can use JobIntentService instead of intent service. It can work.

NotificationListenerService is not getting bound to SystemUI on Android 8 (Oreo)

Based on my testing, it appears that the NotificationListenerService(NLS) in my android app is not getting bound to the system on Android 8 (Oreo). I am targeting my app for SDK version 26 to make it compatible with the new OS.
Prior to Android N, the NLS service was bound to SystemUI forever (Ref: Google I/O 2016). Starting from Android N, two new methods were introduced in NLS service: requestRebind(ComponentName) and requestUnbind().
In Android Oreo, there are new Background Execution Limits that apply to services. However, it does not apply for certain services, such as a "Notification listener that another app binds to". This is my use case, as I am using an NLS service that is supposed to be bound to the SystemUI.
However, as I observed, this service is never getting bound to SystemUI. Additionally, even if I explicitly call requestRebind(ComponentName), the service is never getting bound and hence it is non-functional because this means I am unable to listen to notifications.
How do I fix this problem in Android Oreo?
Oh boy, this is silly! The issue was resolved by a reboot. I suppose Android was misbehaving on my phone and simply refused to work the right way. Rebooting the phone and trying again made the service work the way it is supposed to!
I'll leave this question up as a reminder to all that sometimes the simplest and most cliched fix (i.e. "Did you try turning it off and on again?") is the right answer!
Good grief!

Android O limits for lower target SDK

I started to test my app on Nexus 5x with Android O.
My targetSdkVersion is 22.
In the developer site I read about Background execution limits:
Where:
By default, these restrictions only apply to apps that target O. However, users can enable these restrictions for any app from the Settings screen, even if the app has not targetted O.
Where is these settings (to enforce Android O limitations)?
Whats is the best practice for these limitation while I still want
to keep lower targetSdkVersion?
I found the setting under App info > Battery usage although not all apps have this setting.
When this setting is OFF I see following logs:
W/BroadcastQueue: Background execution not allowed: receiving Intent { act=android.intent.action.$ACTION dat=package:$APP_PACKAGE flg=0x4000010 (has extras) } to $APP_PACKAGE/$APP_RECEIVER
[UPDATE Sep 27, 2017]
As described here:
However, developers cannot use the Settings app to apply this limitation, unless their app happens to be in the battery blame list, which ideally doesn’t happen.
This article offers undocumented way to test background limitations via following command (ignore and allow values are possible)
adb shell appops set your.application.id.here RUN_IN_BACKGROUND ignore
Best practices are
If you plan on sticking with a lower targetSdkVersion for a while, and you are really really sure that your app will not show up on the battery blame list, and you want to ignore the background limitations for now, that’s your decision to make.
If, however, you plan on sticking with a lower targetSdkVersion and your app does tend to consume a fair bit of battery life, you should test your app with the adb shell appops command cited above. If nothing else, you can identify the likely symptoms that users will experience if they limit your background work through the Battery screen in Settings. That way, if you get customer service calls/emails/texts/Play Store comments/candygrams about those symptoms, you can better advise users about what to do.
See also Android Oreo Background Execution Limits
I cannot find it either.
Best practise would be to develop this for API 26, although you are not targeting it. So starting your service(s) as foreground service. After that, your service should start a foreground Notification in the onCreate.
From the docs:
The new Context.startForegroundService() method starts a foreground service. The system allows apps to call Context.startForegroundService() even while the app is in the background. However, the app must call that service's startForeground() method within five seconds after the service is created. (startForeground pushes the notification)
App info > Battery usage
IMO best practice is unfortunately to target API 26... This default behaviour is there only for legacy apps (sitting in play store but not being updated anymore).

Is there a way to use Android system generated notifications in our app

I'm creating an app and its mainly depends on the battery notification which we receive when our battery level is low like 15%. However I know how to get the battery level, but I thought what if there is a way to use the existing notification based on which we can add features.
Please help.
There is a battery low broadcast that you can use, check out the documentation (scroll to "Monitor Significant Changes in Battery Level")
There is no "existing notification", insofar as the thousands of Android device models can do whatever they want when the battery is low. Not all will raise a Notification.
For those that do raise a Notification, there is nothing for you to "use":
A Notification is a Java object; your app cannot access Java objects from other processes
A Notification is configured by a variety of pieces of data; you have no idea what an individual device will use
You are certainly welcome to putter around the AOSP and see exactly what is used for low-battery indications in "stock" Android. Just bear in mind that what you find there is not going to be used on all Android devices and none of it will be part of the Android SDK (other than the generic Notification API).

Categories

Resources