Play Store update apps automatically if there are no change in permissions. But skype asked me to update app and when I clicked on update button I found this popup.
So if there is no permission changed then why play-store showing this dialog.
Actually I developed an app and in that app I did not change any permissions and got same dialog, checked their documentations related to automatic updates but didn't find anything.
This happen to me too, and it took a bit of debugging to figure out. If you go to the app page (before clicking update), and scroll to the very bottom, there is a link to "Permission Details". In my case, it showed "Use accounts on the device", which corresponded to android.permission.USE_CREDENTIALS. You may have a different permission, but if you have the same new one as mine, read on for how I debugged and fixed it.
I didn't add this permission, but doing a grep of my entire build, I saw:
./app/build/intermediates/exploded-aar/com.google.android.gms/play-services-wallet/8.3.0/AndroidManifest.xml: <uses-permission android:name="android.permission.USE_CREDENTIALS"/>
So I suspect some update to google-play-services (or perhaps moving from selective API includes to the whole API include, as delineated in https://developers.google.com/android/guides/setup) caused me to use the google-play-services file and it's AndroidManifest.xml dependencies, including this new permission I never needed. There's more information on this in: Why are permissions being automatically added to my AndroidManifest when including Google Play Services library
By going back to using individual google-play-services packages, I was able to remove Wallet and it's USE_CREDENTIALS, which should help make my installs seamless again.
Incidentally, Android 6.0 Marshmellow removed this permission entirely (see USE_CREDENTIALS not available in new Android M API ), so maybe that has something to do with it? Where Wallet started depending on it automatically in some recent-or-not-so-recent update, since they assumed it'd be automatic in Marshmellow builds, and some apps are now including the permission dependency without being aware of it?
Related
I am getting very conflicting information regarding the use of android.permission.READ_LOGS Android permission. Firstly, the Android Documentation website does not specify the protection level of this permission. It is neither classified as normal, nor dangerous. They do specify the following:
"Not for use by third-party applications, because Log entries can
contain the user's private information."
Some websites say not to use it for the same privacy concerns.
However I have some issue with that:
When I tested this permission in my app on Android 7.1.1 (Nexus 5X) and Android 4.4.2 (old Samsung 8" tablet), neither of them prompted me that the app required this permission. Both said that the app requested "no special permissions". This only happens if the permission is deemed "normal", in which case it is automatically granted.
Secondly, using this permission, I can only view logs from logcat pertaining to my app, which does not log any personal information. Hence, I don't violate any privacy either. I thought this permission may allow me to see other app's logs, causing privacy issues.
So, if this is the case, then is it deemed safe to use this permission in a production version of the app? It would help me a lot in debugging strange bugs users face if they can send me a logcat by the press of a button.
EDIT: Ok, now I am quite confused. It appears that I don't need to explicitly specify this permission in the manifest either.
Is READ_LOGS a normal or dangerous Android permission?
Neither. As of Android 7.1, it is signature|privileged|development. That basically means that apps signed as part of the firmware build or installed on the privileged partition can hold the permission, but nothing else can.
the Android Documentation website does not specify the protection level of this permission
Correct. READ_LOGS is still in the SDK, for backwards-compatibility reasons, but ordinary apps have not been able to hold it since Android 4.1, which came out five years ago.
This only happens if the permission is deemed "normal", in which case it is automatically granted.
No.
I thought this permission may allow me to see other app's logs, causing privacy issues.
It did, on Android 4.0 and earlier.
then is it deemed safe to use this permission in a production version of the app?
Well, bear in mind that there has never been a documented and supported way for apps to access LogCat contents. Most likely, you're using one of the script-kiddie solutions that have been posted, such as running the logcat command and capturing its output. So, it is entirely possible that there are devices, now or in the future, that will not support your particular approach towards accessing LogCat. So, the permission is not your problem; the lack of a supported API for LogCat access is your problem.
Personally, I'd use a logging library to log the content to both a file and to LogCat, using the file for whatever your app needs it for.
I have an already-released android app. If I add a new required feature to a new update, what happens to current users whose devices don't have that feature?
The documentation makes it clear that these users won't see updates since their devices aren't supported. But if they delete the app from their phone, and then try to re-download it, will they see the old versions in the Play Store?
As I understand it, I can't leave the old version of the APK active in the play store since it's filtering on features, not API level or the other requirements. Is that the case?
The users, as you say, will not see an update to the app who don't have that feature. New users (and people who uninstalled it) who don't have that feature will not be able to install the app. They may see it in the store, but they cannot download it.
The only way I know that you can get around this is to release two different apps: one your updated app with the new required features, and the other an old version not having those features. You should make certain to tell users wheather they will be recieving updates with the other app, and you could even put a link to the old app saying If you don't have x or y, go here to download the app:.
Another option is to not require this feature, and to just do it like this:
<uses-feature android:name="x" android:required="false" />
And then you can detect wheather this feature is there in the device, and if so enable some features, if not, disable them.
I have an app with 100k~ downloads on Play, which I started to develop like a year ago. Back then, it had the default crappy android UI. A month ago, I decided to include the ActionbarSherlock+HoloEverywhere libraries, so it could provide a much better user experience, with the Holo UI. Here comes the problem.
I got a few user reports, that they cannot update, since Play is keep telling them, their device is incompatible with the app. NOTHING changed besides adding and using the above mentioned libraries, so their device SHOULD still be compatible with my app. Here is what I know, and tried so far, including reports from the most helpful user, who cooperates with me, and want to use the app.
his old device broke, so it got replaced, and he couldn't install the updated version
on the new device, he can't install the old versions, which he could on the old device
the mentioned device is an atab5 MTK6577
the minimum API level is currently 8 (Android 2.2)
my app requests the following permissions:
android.permission.ACCESS_FINE_LOCATION
android.permission.ACCESS_NETWORK_STATE
android.permission.INTERNET
the features the device has to got are the following:
android.hardware.LOCATION
android.hardware.location.GPS
android.hardware.TOUCHSCREEN
I found a nice tool (http://codekiem.com/2013/02/13/market-helper/) , which I asked the user to try if he can trick Play to install the app, he did, and the app finally installed
after the installation, he got a new error message, "Missing shared library", so he still couldn't run the app
after some research, I found that some device may not have proper Google Maps api, or something like that, but it can be fixed by adding Google Apis to the apk, by explicitly adding Google Api to the Build path
I sent him the newly compiled apk, the new error message is: "Application not installed"
the user has problem with more apps, not just mine, typically with apps that uses GPS, and I guess Google Maps too, so it may be a device fault
as a side-note, I am using standard MapActivity, not the ActionbarSherlock mapactivity, but since the problem is there for the old, non-holo version of the app too, it shouldn't matter
Is there any way for me, to solve the issue on my end? I dont really care, if he still won't be able to run another apps, if he can use mine. Of course, if all his problems would be solved, that is the best case, but my priority is, can I add something to my apk? Or, what is the problem here? A corrupted Google Maps?
Thanks in advance, cheers
after the installation, he got a new error message, "Missing shared library", so he still couldn't run the app
This will come from some <uses-library> element in your manifest.
but it can be fixed by adding Google Apis to the apk, by explicitly adding Google Api to the Build path
Um, no, that will not work.
Is there any way for me, to solve the issue on my end?
Other than by switching to something like OpenStreetMap, no.
A corrupted Google Maps?
More likely it is a device (or ROM mod) that has pirated versions of various Google apps, such as Google Maps, and therefore did not set up the Maps SDK add-on properly.
Why exactly uses-permission
Ex :
<uses-permission>android:name="android.permission.ACCESS_NETWORK_STATE"/>
is needed to access various modules of Android. How is it that just adding one single line that too by the same programmer who is coding it, is actually providing security? I am new to Android programming and this is looking funny. Kindly explain what is the exact use of quoting the <uses-permission>
Google made a whole page to describe the concept. Go through it and you will know the reason.
http://developer.android.com/guide/topics/security/permissions.html
EDIT: In addition to above information. These required permissions are shown to the user at the time of installing the application. They are even visible at the google play store for each app. While most users don't see reqd permissions before installing, some might check them out and if its interfering with their privacy more than required they may not install it or even give bad reviews on play store. These are mentioned in AndroidManifest so Google doesn't have to go through all the scenarios to check what all services the application might request in future.
Whatever permissions you have added in <uses-permission> are actually used later at installation time of your application. User will be asked that this applications require following permissions: Access network states. And if user accepts, the application can be installed. Else application won't be installed.
Refer to this for ore clarification.
If I set in the Manifest.xml and try to install the .apk with ecclipse, the install fails with a missing library error showing logcat. Thats ok for me as developer.
But how will be the behaviour in Google Play?
Simply writing a failure to logcat is not useful for normal users. Useful would be if an appropriate error dialog would appear, informing the user about the error, why and how to fix it (In this case, ideally a link to the missing app in Google Play, so the user can install the missing app easily)
Does anyone know, how exactly the error is handled, if a user try to install the .apk via android market (or other market places)?
Is there a way to costumise that handling?
But how will be the behaviour in Google Play?
The app will not show up in the Google Play Store, if the device does not have the firmware library you require. Hence, the user will not have an opportunity to install it.
This is covered in the Filters on Google Play section of the docs.
Based on the uses-library documentation you can use reflection to determine if a particular class is available. I haven't done this myself but here is a blog spot in which reflection is used to determine if the device support's live wallpapers Using Reflection to test if an Android device is using 'Live Wallpapers'.
It must not be very hard to adapt it for other libraries.
Also, from API 7 there is a android:required value for tag that allows the application to be installed from Google Play even if the library is not present in the user's device.
Hope this helps...