Data security changes in JB break OI Notepad access to OI Shopping List

[aap]

Recently bought my wife a Nexus 7 (2012 edition) which has Android 4.3. She installed OI Shopping List which I built from the ui_update branch, and OI Notepad from the Play store. Upon clicking on a note icon in one of her shopping lists, OI Shopping List tried to run OI Notepad, which promptly failed with a security exception. The same builds work together fine on our phones, which are running CM10 / Android 4.1.2. 

It turns out there are changes to the default security of ContentProviders in Android 4.2, and they are in effect for ContentProviders owned by any app built against SDK 17 or later. OI Shopping List switched to SDK 17 in this commit. If I am reading the documentation correctly, this should mean that if we had released any subsequent version in the Play Store, people would start having permission problems.

There seem to be a few approaches we could take to resolve the issue:

(0) go back to SDK 15... probably not desirable though

(1) set the Shopping ContentProvider as "exported" explicitly -- probably returns our security roughly where it was before

(2) declare explicit read and write permissions for the ContentProvider, and have OI Notepad require them

Any preference? Note that OI Shopping List's AndroidManifest has some permission names for the ContentProvider but they are commented out. If we add them, we would probably have to release updates for OI Notepad and OI Shopping List around the same time.

-- Aaron

[Friedger Müffke]

I vote for (1). We want the shopping provider to be as open as possible.

--
You received this message because you are subscribed to the Google Groups "OpenIntents" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openintents...@googlegroups.com.
To post to this group, send email to openi...@googlegroups.com.
Visit this group at http://groups.google.com/group/openintents.
For more options, visit https://groups.google.com/groups/opt_out.

[pjv]

Just weighing in: I have been using (2) in Collectionista (and its
extensions). Doesn't seem less open to me. Just a matter of the user
accepting it in his app install permissions popup.

Friedger Müffke schreef op zo 01-09-2013 om 09:39 [+0200]:

Pieter-Jan Vandormael

[Friedger Müffke]

With (2) you prevent that an app can delegate using mime-types. All app must know the permission of all shopping apps that they potentially want to delegate to.

I know that there are not a lot of delegation going on at all but that is why we are here :-)

Cheers
Friedger

[pjv]

Hi Friedger,

So you are saying that regular intents don't work? The app does not show
up in the list?

Do you have a reference for that. AFAIK, the permissions are only to
protect the content providers.

Best regards,

Friedger Müffke schreef op di 03-09-2013 om 10:40 [+0200]:

--
Pieter-Jan Vandormael

[Friedger Müffke]

You are right.

I mixed that up. So, wenn you know the URI format to access the content provider then you probably also know the permissions.

So, lets go with 2 ) then.

Cheers

Friedger

2013/9/4 pjv <ezelsp...@gmail.com>