Thanks for sharing the link. I wasn't aware of this bug report. Yes both apps are mine, but even though they have the signature, some user complain about this error. Maybe they installed the apps form different sources, i.e. Amazon and Google Play.
cheers Marten Am Freitag, 20. Februar 2015 12:29:18 UTC+1 schrieb Kostya Vasilyev: > > I'm seeing this with android:protectionLevel="normal" too. > > Since Android doesn't grant permissions that had not been declared yet, > this forces the user to install apps declaring / using the permission in a > certain order. > > This is a pain for the user, so the developer of one app that works with > mine (and needs a permission declared there) added an identical permission > declaration stanza in his app too. > > A clever hack, on Android prior to 5.0, it lets the user install mine and > his apps in either order. > > Since Android 5.0, only one app can be installed at a time -- trying to > install the other one fails with Play error code 505. > > I don't work for Google, so can only post a link to the bug tracker -- > https://code.google.com/p/android/issues/detail?id=79375 -- and maybe > recommend trying "signature" protection level, since both apps are yours > and (as I understand) you hadn't released the new one yet, so you can still > make that change. > > -- K > > On Friday, February 20, 2015 at 11:33:25 AM UTC+3, marten wrote: >> >> Hi Marina, >> >> we're using android:protectionLevel="dangerous" because that's what we >> think is suitable for personal data like tasks. Also, it's what the >> CalendarProvider uses for the permissions to read and write calendars. >> >> At present the major issue is that some users get this error even though >> they install the properly signed version from Google Play. >> >> The root of all this is that there is no way to grant a permission that >> hasn't been granted at installation time. And Google is making it worse >> instead of fixing it. At present the only solution seems to be to use no >> permissions at all and that's certainly not what this is intended for. >> >> If there is someone from Google in this Forum: How is this intended to >> work? >> >> thanks >> >> Marten >> >> Am Donnerstag, 19. Februar 2015 19:21:40 UTC+1 schrieb Marina Cuello: >>> >>> Hi! >>> I'm not sure how to help, because've only met this problem when there >>> are several users set on a device. >>> >>> If I install my app directly from Eclipse with my debug certificates, >>> then uninstall the app and try to install a production copy, made with >>> the release certificate, I've got the same error message >>> INSTALL_FAILED_DUPLICATE_PERMISSION. >>> >>> Until I uninstall the app in every user by hand, I can't install the >>> new one. At least in your case the error message makes sense :) >>> >>> When I was trying to understand that error message, I've read that it >>> affected permissions with android:protectionLevel declared as >>> "signature". Are you using that? Can you change it to "normal" without >>> affecting your business model? >>> >>> >>> Marina >>> >>> On Wed, Feb 18, 2015 at 11:58 AM, Marten Gajda <mar...@dmfs.org> wrote: >>> > Hi all, >>> > >>> > we've some problems with Android 5. There seems to be a new policy >>> that >>> > requires two apps that define the same permissions to be signed by the >>> same >>> > key. Otherwise you can't install the app getting the error >>> > INSTALL_FAILED_DUPLICATE_PERMISSION. >>> > This is very annoying and I'd like to know that the suggested >>> > solution/workaround to this is. >>> > >>> > We have an Open Source task app that provides access to the tasks via >>> a >>> > ContentProvider. The concept pretty much equals the CalendarProvider. >>> We >>> > also have a (not yet Open Source) sync app that can sync to this task >>> app >>> > (or its ContentProvider). >>> > The problem is that (in contrast to the CalendarProvider) our users >>> usually >>> > install the sync app first. That means the permissions of the task app >>> are >>> > not known when the sync app is installed. So they are not granted >>> > automatically when the task app is installed afterwards. >>> > >>> > Until Android 5 the solution was to define the same permissions in the >>> sync >>> > app. But that doesn't work any more in some cases. If the user >>> compiles the >>> > task app himself he can not use our sync app at the same time, because >>> they >>> > are not signed by the same key. >>> > >>> > How can we achieve that we protect access to the task ContentProvider >>> by >>> > permissions still allowing them to use a self compiled version? >>> > >>> > Even if both apps are signed by the same key it doesn't seem to work >>> in some >>> > cases (does Android 5 also require both apps to be from the same >>> source?) >>> > >>> > A similar issue exists when another developer tries to build a sync >>> app that >>> > can sync to our task app. He can not add the same permissions, because >>> he >>> > can't use the same signing key. But if he can't add the same >>> permission >>> > definition his app won't get the permission if it's installed before >>> the >>> > task app is installed. >>> > >>> > What's the solution of this mess? >>> > >>> > thanks >>> > >>> > Marten >>> >>> -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
