Android Pie (Nokia) - Foreground Scanning Service scans for sometime and then scanning stops when app is in background. #807
Comments
shriharsha-bhagwat
changed the title
|
Thanks for this report. I have not seen this before. I will attempt to reproduce with the reference app with a foreground service enabled on a Nokia 6.1 plus with Android 9. I'd be curious to know if you see anything special in LogCat (from the OS or from app logs) when the scans stops. I understand this is difficult to capture this if it takes 12 hours for it to happen. |
|
I captured the following after approx 28 minutes scanning in the background (and with the screen off) with the reference app and foreground service enabled: After I saw the above, I illuminated the screen and it still detected zero beacons. I then brought the app to the foreground, but it still detected zero beacons. Killing and restarting the app caused it to resume detecting beacons normally. I'm not sure if this is a bug in Android 9.0 (or the Nokia ROM) or intended behavior. I am going to try to reproduce again and see if when the condition occurs, if settings indicates the app has been granted location permission or not. |
|
Right before the above SecurityException happened, the library tried to stop and restart the scan per these log lines: This is a library feature that will stop a constant scan after 30 minutes if it is on Android N+ and then restart it. But it seems in this case the new scan is blocked with that SecuirtyException. |
|
Reproduced the problem a second time -- it takes exactly 30 minutes to get this in the background. Then when I go to Settings -> Apps -> BeaconReference -> App permissions I can confirm that it says it has Location permission. |
|
Another test to see if scans are always blocked from starting in the background for foreground service apps on this device:
This proves that the exception does not always happen for starting scans in the background with foreground services. |
|
Thanks for trying out to reproduce the issue. Yes it takes 30 minutes atleast to reproduce this issue. The code actually works good in Oreo (Tried in Pixel). But not sure why it does not behave the same in Pie (Tried in Nokia). |
|
Is there any solution which can be tried out to solve this issue? Please let me know. |
|
I would suggest testing a betweenScanPeriod of 100ms to see if this alters the behavior |
|
I tried this and still the same. It did not work for me. Not sure how to proceed. |
|
Discoveries from a few further tests:
|
|
I also verified that if you do not use foreground service scanning with the library and instead use the default job scheduler running scans every ~15 minutes, the scans do succeed without a SecurityException. So the default behavior of the library without a foreground service works as expected with Android 9 So this appears to be that: Apps targeting SDK 28 with a foreground service starting BLE scans after > 5 minutes of running in the background on Android 9 will get a SecurityException trying to start a BLE scan. (Only seen so far on Nokia Android Pie ROMs) It is unclear if this is an intended behavior of Android 9 or if it is a bug in AOSP or the Nokia ROMs. While Nokia Android Pie ROMs are part of AndroidOne, so supposedly stock AOSP, if anybody has a Pixel device with Android 9.0 test this with, I'd love to get a confirmation of whether the problem exists there. |
|
I can verify in Google pixel today. And also if i run scans every 25 minutes using AlarmManager or Job Scheduler, what will be the behaviour? Will scans run continuously or will there be gaps in scan results as scheduler execution might be varied? |
|
AlarmManager cannot run on Android 8+ in the background. JobScheduler can run for up to 10 minutes every ~15 minutes but there will be gaps for sure, as the 15 minute cycle can vary by +/-10 min. So neither of these will allow constant scanning. Please let me know what you see with a foreground service with constant scanning on a Pixel with Android 9. |
|
Sure thank you. I will let you know by EOD. |
|
I tried the same with Google Pixel running Android 9 and it works completely fine in it. How can i proceed to make this work in Nokia 6.1 Version 9 as well? Any suggestions? |
shriharsha-bhagwat
changed the title
|
I tried the same with a OnePlus 5T running Android 9.0 and it works fine too. targetSdkVersion is 28, using a foreground service, scanning is still running after 45+ minutes with app in background, and screen off |
|
This appears to be a bug in Nokia Android 9.0 ROMs. The same behavior does not happen on a tested Google Pixel 9.0 ROM nor on a tested OnePlus 5T Android 9.0 ROM. Further, this is not a documented change in Android 9.0. I have confirmed you can get around this by changing to |
|
This was logged with Nokia here and in an email to support. Unfortunately, I am told by their support they do not have a public bug reporting system. |
|
Yeah seems like bug in Nokia. Will try to get around it as you have said and will get back to you. @davidgyoung Thank you for all your inputs. |
|
I tried with targetSdkVersion 27 in Nokia. I see scanning gaps when phone goes to background. |
|
@android-bash, I received a reply from Nokia support, and they suggested doing the following:
I performed the steps above to humor them, not expecting them to help. To my surprise, however, after performing the above I can no longer reproduce the problem on my Nokia 6.1 Plus 9.0. This won't do anything to fix such problems with the wider user base (good luck getting all Nokia users to do this) but it suggests the problem has something to do with phone state. Can you please try the above and see if you can confirm the same? For what it's worth, after the problem went away, I re-enabled bluetooth scanning per the first step, rebooted, and confirmed I was still able to scan for more than 5 minutes with the screen off with a foreground service. |
|
Wow something to try out. I will also try this and get back to you. Thanks @davidgyoung |
|
@android-bash, please do try the steps above when you have a chance and let me know the result, I'd like to get confirmation if this helps from more than one affected device. |
|
@davidgyoung Sorry i did not have access to Nokia device from past few days. Tomorrow i will try this out and get back to you. |
|
Wow, I just read this, and really all I can say is wow. Since it looks like a security issue, have you tried to query the Location (and potentially phone state) permissions again during the process in which you stop and restart the scanning? I wonder if that would have any affect? We all know that it probably shouldn't... but I'd still be tempted to see if it makes a difference. Maybe Nokia is putting some kind of timeout on the permission duration? I've known Nokia to have different interpretations of specs before, and would not put it past them. Update: I set up my app to do periodic permissions checks to see it it would help, but I still got the same error about the binder call failing. I have not tried editing the library, I think it still would have failed. Question: If I use the steps above to "fix" the issue, is there a way to get the issue back again? Question 2 Is there a way to do those steps programmatically in my app? |
|
@joew46167, I did check permissions when the phone was in this state of blocking scans, and the OS reported then as being granted. Based on my comment from Nokia support, I did see that doing their Bluetooth reset procedure made the problem go away. I would like somebody else to repeat this to confirm, but if it is confirmed this suggests a bug triggered by stateful condition and not intended behavior. |
|
And to answer your other questions, I have not been able to reproduce the problem since the reset procedure. I highly doubt there is a programmatic way to do the same. |
|
Thanks for the information David.
My app is designed for blind people to use. That procedure would be difficult for them to follow. So if I can’t reproduce the issue after running the procedure, I’d rather not run it until I exhaust all other options. I’d like to continue testing. So for that reason I’m hesitant to run the procedure at this time. The rest of my team concurs.
Tomorrow I’ll have a Pixel 2 to test with. I hope that you’re correct and it works better.
Again, thanks for your help.
Joe
|
|
@davidgyoung That's why I'm hesitant to do it. I'm stubborn and not yet ready to stop trying to find a better way. An interesting thing - before I found your library, I created my own. It worked pretty well, but had some stability issues. I was hoping that moving to the beacon would help with those stability issues. so I started the migration. I didn't have the Nokia phone yet when I started the process. ad I had been doing most of my testing with the "keep screen on while charging" option turned on. and I have the phone connected for logging, so it was always charging. So it took a while before I ever saw the issue. Now I've gone back for a bit to using my old code, just to see what happens. I had also found by trial and error that I needed to stop and restart scanning periodically. The bad news in my old code is that after the screen is off, the scans stop, and I get the same COARSE_LOCATION error message. the good news in my old phone, though, is that when I turn the screen back on it appears to recover, although I admittedly need to do some longer duration testing yet. I wonder if maybe I inadvertently stumbled on a way around this? I'll let you know more tomorrow. Lastly, if you were to do a factory reset, would you get the issue back so you could resume investigation? I'm guessing you've already tried that. |
|
I did not try a factory reset. I suspect however that a factory reset would have also cleared the error condition in a way similar to resetting the Bluetooth settings. I say this because the error condition happened right after the Android Pie upgrade. I suspect the upgrade process is at fault, basically retaining Bluetooth state data from Android 8 that does not work properly with Android Pie on Nokia phones. Juat a theory. |
|
@davidgyoung Hate to say it, because I hate disagreeing with smarter people, but I think your theory ay be wrong. And here's why. I got my unlocked Nokia 7.1 in mid December. During the setup procedure it did an upgrade to Pie, So I've never done anything with this phone that wasn't done on Pie, and I'm still seeing the issue, I don't think there could have been any data on my phone to retain from Oreo. Granted I could be wrong. But my gut feeling is after a factory reset and getting to Pie again, even without running anything Bluetooth pre-Pie you'll see the issue. Just my feeling. |
|
@joew46167 what you suggest is certainly possible, although I think a migration problem could happen even with very limited Bluetooth state data. If I do a factory reset I will let you know what I see, but as I am using it as my primary device, it is not a quick test to do. Please let me know the results if you try the same. |
|
@davidgyoung Is there any way to accelerate testing? That half an hour before the issue occurs is tough! |
|
Hello @davidgyoung I never did do the ugly "fix" procedure that you got from Nokia. However yesterday I did do a factory reset of the phone, and the issue is still present. IDK if that is useful information for you. |
|
I have same issue. Using library in foreground service and it works like a charm some time and then it stops scan for a while and start again. I have same behaviour on 3 different devices (Moto Z Play 8.0, Samsung A7 8.0 and Nokia8 9.0). Only thing i get from log is:
Any suggestion on how i could fix this? Thanks |
|
For the Nokia phone I'm still searching for a good way around this. I'm starting to lean toward detect and report. I'm a little surprised by the Moto Z, but it is what I've had the least testing time with. As for the Samsung, as David mentioned earlier, you can see #769 - which basically says to make sure you're using the latest version of the library. Lastly, David has asked that we limit this issue to Nokia phones. |
|
@joew46167 Thanks. i was using 2.15 instead of 2.15.2. Will try that. Since Nokia was accused for having too aggressive background task manager (package: com.evenwell.powersaving.g3) that kills background activity of some apps after 20 minutes , maybe it can be one of the reasons for lib issue. |
|
@cobainmo I even had trouble with 2.15.2. I went all the way to 2.15.4 |
|
@cobainmo, any issues with Samsung, please comment on #769. The core issue may be entirely different on each manufacturer phone. Feel free to open a new issue for the Moto Z, but please make sure any logs you post are for the specific device associated with the issue. It is also very helpful if you include system-level logs in your excerpts (not just log lines originating from your app process) because system level logs from the bluetooth stack often give clues to what is going on. An example is the Nokia system log line about permissions mentioned above. Finally, please keep this issue focussed on Nokia so we don't confuse ourselves. |
|
I just saw this Nokia Security update article. Do you have any sight into what is happening at Nokia to know if this will address this issue? |
|
Unfortunately, I see nothing in the descriptions of those security patches that looks like they would address this issue. |
|
@davidgyoung H. I'm not sure what you'll be able to do with this, but I'm sharing it with you anyway. On my Nokia 7.1 running Pie, I went though the procedure you put in a comment above, my plan being to do a factory rest later to see if this issue comes back. However, I still get the same results - after about 10 minutes with the screen off I start seeing and after 30 minutes I no longer get any ranging information. One thing that I didn't expect - after the soft reset the screen showed a sick Android with it's chest open and the words No Command on the screen. I'm not sure what that was about. I had to power off and on again. I thought maybe I missed something, so I went through the entire process a second time with the same results. I haven't bothered with a factory reset. |
|
@joew46167, this suggests that the procedure from Nokia is not 100% effective. Since you repeated it twice, this makes it unlikely that you accidentally skipped a step. For the record, I did not see a "No Command" Android graphic like you describe when I went through the procedure. |
|
I can also confirm that above procedure with clearing cache is not working on Nokia 8 Android 9 (with latest security patch installed) along with soft reset. I didn't have issue like @joew46167 it started normally, but i still keep getting "Need ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission to get scan results". @davidgyoung since i am trying to switch app from using "Estimote" library to AltBeacon i can confirm you that this issue does not occur on Estimote and Beacon scanner is working properly. I dont know if it helps you but id does not seem its just Nokia side issue. |
|
@cobainmo that's interesting that the Estimote API doesn't give you this issue. I previously had rolled my own BLE scanner, and I see this issue with my handler as well. That was part of the motivation for switching - I had hoped to have better results with the library. For most phones, it is better. For the Nokia, it's about the same |
|
@joew46167 yes, i can confirm that. I have access to 30 different devices with android 9 Including various Nokias that have Estimote lib and its working. To be honest i had same behaviour with few different brand. It has same issue as Nokia but different logs. Point is it stops after a while then come back by itself. I will take few day to test it in detail and probably open new issue if it turns out not to be Nokia problem. |
|
Hello, is there any new info about this issue? Last 5 days i was running test on few Nokia devices as well as other manufacturers with android 9. Problem is definitely related to Nokia. On other vendors works fine. On the other side, Estimote lib still works on Nokia 8, Nokia 7.1 with android 9 so it got to be related to Altbeacon lib. Log:
|
|
@cobainmo To be honest, I've moved on, and have just put in a check to see it is still connected to the beacon scanner, and if not I tell the user (my app speaks anyway, as it is for blind people) that if they turn the screen on for a moment it will likely solve the issue. It is interesting that the Estimate API has found a way around this. I wonder if it might have to do with frequency of restarting the scan? I believe that the library is currently restarting every 29 minutes - just often enough to circumvent the 30 minute issue. After my testing, my gut feeling (with no true evidence or testing) is twofold:
I also have a feeling that Google will catch on to our attempts to circumvent the 30 minute limit and shut that down, too. |
|
@joew46167 why do you think restarting a scan every 1 min would help? I am certainly open to ideas like this to try, as I don't know what is different about the estimote approach that would make it work. (They might not know either, it is probably by accident!) |
|
@davidgyoung I'm about to do a test, but if I remember correctly, my hand built BLE code didn't have this issue with Nokia phones. And I was doing restarts every minute. It's been a while since I've used that code, I've slept since then, and I just can't be sure if I had the issue or not. As I said, though, I am going back to that code now and testing - I have other tests to do in that code as well. I'll let you know the results. |
|
@davidgyoung i think you are right about Estimote and accident since they have other more obvious issues unsolved. Anyway this lib works great and i will leave estimote just for Nokia phones for now. If in some future you find out solution let me know. @joew46167 i'm moving on too :) at some point i just doubted that it is only Nokia issue. After all testing, looks like i was wrong. |
|
@cobainmo I worry that your fear could be correct, that it's not just for Nokia, so I left my code agnostic - I do the check and make the suggestion to unlock the device for all devices, not just Nokia. |
|
@davidgyoung My memory was wrong. My hand rolled BLE handler does indeed fail and presents the permissions error. In it I restart the scanner every minute. At the 10 minute mark is when the permissions error occurs. I wonder if the Estimote library found a way to not require the periodic restart, and that is how they bypass the issue? |
|
I had the same issue (with my own code). In addition, I had my app being killed after some time (I am using the Foreground service approach). After some searching, the latter apparently was due to aggressive service killing on the Nokia, as reported here: https://dontkillmyapp.com/nokia. Killing the killer as instructed on that site fixed this, but also appears to silence the issue being reported/discussed in this thread (ie I saw no more scan security exceptions). I have no time to further investigate or reproduce this, but it may be a useful piece of information, hence this post. |
|
For me the Settings provided by Nokia (clearing storage etc) did not work on my Nokia 6.1 running Android 9. What worked is force stopping the PowerSaver.G3 system app inside Nokia. Scan runs smoothly for hours if i force stop the PowerSave.G3. |
|
I just noticed the following in the reference app's manifest, maybe it would resolve this issue? <!-- uncomment the following to enable scanning for over 30 minutes on Android 7+ -->
<service android:name="org.altbeacon.beacon.service.BeaconService"
tools:node="replace">
<meta-data android:name="longScanForcingEnabled" android:value="true"/>
</service> |
|
Any updates on this issue? HMD Global (i.e. Nokia) claims to disable Evenwell powersaving apps on all devices running Android Pie or newer which means the foreground scanning service may be able to run in background. See here: https://community.phones.nokia.com/discussion/51246/tapping-into-android-pies-adaptive-battery-for-optimum-battery-performance I tested my app on a Nokia phone(Nokia 7.2 with the latest android version). My app is able to run in the background for more than an hours. However, the beacon scanning(with using Foreground Service Scanning approach) is found to be stopped after 30 minutes background operation. |
Expected behavior
When Foreground scanning service is enabled it should scan always
Actual behavior
Scanning works for sometime(1-2 hours) and then scanning stops when the app is kept in background for a long time.
Steps to reproduce this behavior
Let the scan start and leave mobile idle for more than 2 hours. Scanning return empty list of beacons
I have attached code.
Mobile device model and OS version
Nokia 6.1 Android PIe OS Version 9
Android Beacon Library version
2.15
My Code: How can i run the scanning for a long time (10-12 hours) continuously on Android 8 and Android 9?
The text was updated successfully, but these errors were encountered: