Richard,
I'm finding the content authority
'com.android.inputmethod.latin.dictionarypack' to be part of the Gapp
LatinImeDictionaryPack.apk. I'm not seeing this app or content authority
in AOSP. Are you including any other non-AOSP apps in your build or am I
missing something. And, while
packages/inputmethods/LatinIME/java/src/com/android/inputmethod/latin/BinaryDictionary.java
seems to define the string
"com.android.inputmethod.latin.dictionarypack", the actual content
provider is implemented in LatinImeDictionaryPack.apk (just using
apktool to dump the manifest and looking for the provider tag reveals
this). If this is all true, the best approach is to add a
content_permissions.xml under the device or vendor tree and UNION it in.
Bob
On 07/15/2013 06:46 AM, rpcraig wrote:
On 07/14/2013 08:25 AM, Richard Haines wrote:
In the ActivityManagerService.java source there is the following
comment:
// Is this the best spot for this? Should we specifically let the
// other tests below try first and then right before a return
// is made do we try to apply our checks? That approach might
// make sense becuase maybe that provider doesn't even exist.
The author is correct in that this is not the correct place. This is
because
apps like "com.android.inputmethod.latin" can never run as it needs
to load a
dictionary CP as a part of its process. I've therefore added the
checkPolicy
call to various return points in the process. It may be that the call
should
be added to more places, however the patch works with my simple tests.
The original checkPolicy() covers you're three new places already, so
I'm not sure what you're actually gaining by removing the old check.
The reason you're getting a denial is because there is presently no
policy in place to deal with this specific provider; a minor oversight
on our behalf as we probably didn't exercise all the apps. I think the
correct course of action is to address the denial by just creating a
new policy entry in content_permissions.xml. Maybe try something like
the following; we'll probably have to create a more appropriate type
in the future. Or, we could even try to add this specific provider to
an already existing type stanza protected by a signature.
<type name="com.android.inputmethod.latin.dictionarypack">
<provider value="com.android.inputmethod.latin.dictionarypack"/>
</type>
<allow source="shared"
destination="com.android.inputmethod.latin.dictionarypack"
permission="use;rw"/>
On a side note, did you have to create any new policy for this content
provider after you moved the existing checkPolicy() hooks? If not,
doesn't that seem a bit suspicious? I would expect one of your new
hooks to throw a denial.
The attached patches:
frameworks/base/services/java/com/android/server/am/ActivityManager.java
The main symptom is that the popup keyboards did not work when
editing text
and is shown in the logs as:
D/ActivityManager( 336): Denied USE permission between caller=xxx
and content authority=com.android.inputmethod.latin.dictionarypack
Where caller=xxx is the pid of the com.android.inputmethod.latin app
"com.android.inputmethod.latin.dictionarypack" is defined in:
packages/inputmethods/LatinIME/java/src/com/android/inputmethod/latin/BinaryDictionary.java
String DICTIONARY_PACK_AUTHORITY =
"com.android.inputmethod.latin.dictionarypack";
Richard
--
This message was distributed to subscribers of the seandroid-list
mailing list.
If you no longer wish to subscribe, send mail to
[email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
