We have a weather app for Android that also provides a widget.
The widget displays the current time and weather for the current user location.
We update the widget clock every minute (via AlarmManager) if the display is active, the weather data at longer intervals. Sometimes the widget "freezes". We were able to track that down to the alarm for the next check not being set but don't have a clue why, yet.
Now we noticed the following warning in the device logs of an affected device:
03-12 10:15:44.803 771 4958 W ActivityManager: Permission Denial: opening provider com.google.android.gsf.gservices.GservicesProvider from ProcessRecord{41a4d028 25012:com.my.app/u0a88} (pid=25012, uid=10088) requires com.google.android.providers.gsf.permission.READ_GSERVICES or com.google.android.providers.gsf.permission.WRITE_GSERVICES
This starts to appear exactly at the time where the clock should have been updated. The message is then repeated several times until the ActivityManager terminates the process.
We use the Google Play Location Services to get the current (or last known) location of the user. I found references to a bug in version 4.2 of the services (here and https://stackoverflow.com/questions/22682538/when-to-use-read-gservices-permission) that could cause this error, but the device has version 6.7.76 installed.
One more thing to consider is that the device is running Cyanogenmod, though the stuck widget problem also happens on devices with "regular" Android.
Any hints what could cause this permission error are very much appreciated. Thanks!
Edit: The widget and app work fine on that and many other devices until the warning appears. Also the Google documentation is not mentioning that you need to get those permissions. In fact the only mention of those is here in this document according to the on site search, but no mention of READ_GSERVICES on the page itself.
The two permissions it is asking for:
<uses-permission android:name="com.google.android.providers.gsf.permisson.READ_GSERVICES"/>
<uses-permission android:name="com.google.android.providers.gsf.permission.WRITE_GSERVICES"/>
Something to remember just because this issue was reported in Google Play Location Services in 4.2 does not mean it has been fixed. It may be worth looking through the Google bug reported to see if anyone has any issues. I found a few issues raised running much newer Google Play Services.
Upon doing a quick Google search myself it seems like the major problem phones are the Moto X and the Nexus 5. Which is rather interesting as they are both Android Open Source Project bugs (i.e phones running stock Android with no skin!)
Just a few questions:
Can you confirm what phone you have and which version of Android you
are running please?
Also what is your target SDK?
What version of play services are included in your APK?
Related
We have an app utilizing NFC and recently migrated from enableForegroundDispatch to enableReaderMode. Since then, we have been receiving bug reports where the user intermittently has trouble scanning tags.
I was troubleshooting remotely with a customer today who was unable to scan any tags (the app was working through yesterday). Sometimes they would receive an "NFC read error. Try again" message.
When we had them install the older version of our app which uses enableForegroundDispatch, NFC scans worked as intended. Scanning using the NFC Tools app was also working during this time, as was scanning with no app open. We tried rebooting the device and also toggling NFC on / off with no luck. It was just our app.
After much debugging, what appears to have resolved it was to fully delete our app from the device and then reinstall it. The device is a Google Pixel 2 running Android 11.
I have read countless threads about enableReaderMode and am also aware of this bug affecting kiosk apps in Android 11 (but our app isn't a kiosk). I also read about how there is a bug where Android might think our app is not in the foreground.
Is there any credence to the theory that deleting our app (vs. updating the same installed package with different builds) is what resolved this, and if so then what exactly is happening that is causing this?
Edit: I just found the threads about "NFC service dead" and am guessing this is what happened.
I have read the public code for NFC service, I cannot remember it having anything that would be affected differently by update vs uninstall/install other than possibly the Manifest(PackageManager?) permission to use NFC.
I have not looked in to details about how an app update updates the Manifest permissions, but guess an update might not update the permissions if it thinks they are not changed whereas remove/install would probably delete the whole entry and re-add it thus if there was corruption in the permission list a remove/install would likely fix it.
Also if the NFC Service is dead then other App's would not scan as well. I do seem to remember there is something in there to restart the NFC service if it had died.
I am talking about the quality issue (bug) that an Android app needs a permission that is declared in the Manifest, but fails to request it from the user at the appropriate time and executes the code without the necessary permission. This was not possible in older Android versions (user accepts all permissions in bulk), but seems to be possible when using newer versions that copy Apple in most regards.
At least during testing one can start background services and use bluetooth without any alert by Google popping up. Is that different for apps in production?
Does the app crash with an Exception?
Does the code get executed?
Does the app get rejected in review? (Always?)
Does the app get delisted from the store?
Does it depend on Android's Version?
I deal with an age old app that has bluetooth discovery code to find and connect to dedicated hardware, that is rarely used via a cordova plugin triggered by content. There is old altbeacon code potentially activated that may even need access background location (https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions). It will take some time to get this dead code up to quality. Definitely more time than the week we have.
Does the app crash with an Exception?
yes if you try to have operations depends on returned date witch is null
Does the code get executed?
code will execute with exceptions because data access denied you can check if permission granted or not and add scenario for each state
Does the app get rejected in review? (Always?) not sure but with crashes there is high potential to get rejected
Does the app get delisted from the store?
depends on why and how you are using data
Does it depend on Android's Version?
yes access data and permissions changing point is android oreo
My tests with Bluetooth permissions revealed the following: Required permissions are BLUETOOTH_ADMIN, BLUETOOTH and for VERSION_CODES.Q additionally Manifest.permission.ACCESS_BACKGROUND_LOCATION (see: https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions).
BLUETOOTH_ADMIN, BLUETOOTH do not show any system alert-dialogue to the user. In Android Q+ if you fail to check for the required ACCESS_BACKGROUND_LOCATION permission, nothing happens and your code executes without exception (mine did execute an UART command on hardware with Samsung tablet). The app passed review although the check is missing (of course I will fix that ASAP).
Note: the doc is ambiguous and states: "Services running on Android 10 and higher cannot discover Bluetooth devices unless they have the ACCESS_BACKGROUND_LOCATION permission." Probably general scanning while the app is active could be allowed. In that case missing exception would be explained.
I have a similar issue to this post How to make my Android app comply with the "Background Location Policy" but that post doesn't have an answer.
I have a web browser app, which on occasion will ask for location permissions if the user visits a website that requests that. App targets API 29. The app manifest has <uses-permission-sdk-23 android:name="android.permission.ACCESS_FINE_LOCATION" /> which is API 23 and higher because I didn't want to force location permission on older phones.
Today I got an email saying I have until March to fix this, but I don't understand what I have to do, I'm not requesting background location anywhere.
Anyone have any idea what I have to do?
Edit: I have read the help center, and I'm wondering if that my issue is the ACCESS_FINE_LOCATION, maybe something is accessing it on the background. I don't know how I would prevent ad networks from that if they do it. I already pause the WebViews the app is not on the foreground so websites should not be using it.
Edit2: Is there maybe a way I can log background location access so that I can monitor my app a few days to see if it happens?
I would like to answer my own question in case someone else is searching for this. I can't say that I know for certain this is correct but it has worked for me so far.
First, on this answer https://stackoverflow.com/a/65894488/704836 I was told to use AppOpsManager to log background location requests. After doing that I found a few places where that takes places. I will discuss those below:
Ad networks. I have ad network initialization on my Application.onCreate() and a lot of those accessed location. So when triggering a BroadcastReceiver, they would check location.
WifiManager.getConnectionInfo() - this will trigger a location request. Same deal as above, I had one of those on Application.onCreate().
After removing those calls the Play store stopped complaining.
I have an app that allows users to login using fingerprint authentication. The feature has been in production for a couple of months, but in the last day I started seeing many of these exceptions:
java.lang.SecurityException: Must have android.permission.USE_FINGERPRINT permission.: Neither user ##### nor current process has android.permission.USE_FINGERPRINT.
The crash occurs when I call fingerprintManager.isHardwareDetected() to check whether or not the device supports fingerprint authentication. I have the USE_FINGERPRINT permission declared in the manifest, so I don't know why the system would think that the process does not have this permission. This should not be something that I have to check at run time since USE_FINGERPRINT is a normal permission.
This has been working fine for months, and when it started crashing yesterday, we had been on a stable release for about a month. This problem sounds almost identical to this FingerprintManager.isHardwareDetected() throwing java.lang.SecurityException?. I am only seeing the crash on Oreo devices.
My current plan is to catch the Security Exception and proceed as if the device did not have the hardware, but my worry is that this might mean that no one is able to use the feature for login if this problem persists. Has anyone else had a recent issue with this exception? Or if not, does anyone have any ideas about why this might have just started happening all of a sudden like this? Thanks for the help!
Use the FingerprintManagerCompat instead, that was handling permissions correctly for me.
See:
https://developer.android.com/reference/android/support/v4/hardware/fingerprint/FingerprintManagerCompat
Additionally you might want to declare the permissions in your Android Manifest:
<!-- Fingerprint -->
<uses-permission-sdk-23 android:name="android.permission.USE_FINGERPRINT" />
Note that I used uses-permission-sdk-23, since I found that FingerprintManager doesn't work reliable in older versions of Android, I know there are some Samsung Galaxy devices with fingerprint reader, but before API 23 you were granting permissions at installation time; that depends more on your market. Try it and see if it makes a difference for your users.
See: https://developer.android.com/guide/topics/manifest/uses-permission-sdk-23-element
So I have an app that works flawlessly on many devices. The problem is on one specific phone with Android 6.
The location for our app only works when another app uses the GPS.
For example, starting our app, the GPS icon starts as if the GPS was active but location updates on the app do not appear or refresh. Then, we start Google Maps and only then locations on our app start getting refreshed. As soon as we close Google Maps, our locations stop being received.
I actually tested the app on another phone with Android 6 with no problems.
I think there might be some kind of issue with Google Play Services or with the new the permissions schema. Or maybe with BroadcastReceiver receiving the position updates.
Key information:
Our app es compiled for SDK 22 with Google API.
Google Play Services version on the phone with the issue is 8.4.92
The app uses this version of play services:
compile 'com.android.support:appcompat-v7:22.2.0'
compile 'com.google.android.gms:play-services-location:7.+'
compile 'com.google.android.gms:play-services-maps:7.+'
compile 'com.google.android.gms:play-services-gcm:7.+'
All permissions are activated for our app on that phone.
The phone with the problem was working fine before it got updated to Android 6.0
We tested on another device with Android 6.0 and had no issues.
The phone is in a client in another continent so we don't have access to debugging or logs. No errors occur though because we would receive those on Fabric.io.
We use a Broadcast to dispatch new positions to a service and an activity so the problem might be there.
Im running out of options and tests.
Any ideas?
Thanks,
EDIT
The problem is that on that version of Android, getSpeed from Location is always 0.0, unless another app is using the location, then we get updates with the speed included.
This really sounds like a bug. Why would legacy apps not get the speed in the location? Assuming its because we use API 22.
On a side note, we use speed to filter out positions and stop updating location when the phone is standing still. Thats why we did not see location updates.
I guess we will have to calculate our own speed.