Tuesday, April 17, 2012

SecurityException: caller uid XXXX is different than the authenticator"s uid


This is for the record only. I received the above exception when trying to implement Sample Sync Adapter application. I have seen numerous posts related to this issue but no satisfactory response. So I will jot down my solution here in case anyone else gets into the same issue.



First, check the condition explained on this post http://loganandandy.tumblr.com/post/613041897/caller-uid-is-different



Second, if you are like me and want to embed the sample into your existing app for testing then make sure you use Constants class that is part of this example and not under android.provider.SyncStateContract package. Because both classes use the same attribute name ACCOUNT_TYPE that is used when creating Account object.



HTH, Paul


Source: Tips4all

3 comments:

  1. @jcwenger - Thanks for noticing that.

    Answer copied and pasted below.



    I received the above exception when trying to implement Sample Sync Adapter application. I have seen numerous posts related to this issue but no satisfactory response. So I will jot down my solution here in case anyone else gets into the same issue.

    First, check the condition explained on this post http://loganandandy.tumblr.com/post/613041897/caller-uid-is-different

    Second, if you are like me and want to embed the sample into your existing app for testing then make sure you use Constants class that is part of this example and not under android.provider.SyncStateContract package. Because both classes use the same attribute name ACCOUNT_TYPE that is used when creating Account object.

    ReplyDelete
  2. Some other useful tips to debug problems like this.

    First enable verbose logging for some tags:

    $ adb shell setprop log.tag.AccountManagerService VERBOSE
    $ adb shell setprop log.tag.Accounts VERBOSE
    $ adb shell setprop log.tag.Account VERBOSE
    $ adb shell setprop log.tag.PackageManager VERBOSE


    You'll see logging like this:

    V/AccountManagerService: initiating bind to authenticator type com.example.account
    V/Accounts: there is no service connection for com.example.account
    V/Accounts: there is no authenticator for com.example.account, bailing out
    D/AccountManagerService: bind attempt failed for Session: expectLaunch true, connected false, stats (0/0/0), lifetime 0.002, addAccount, accountType com.example.account, requiredFeatures null


    Which means that there is no authenticator registered for this account type. To see which authenticators are registered watch the log when installing the package:

    D/PackageManager: encountered new type: ServiceInfo: AuthenticatorDescription {type=com.example.account}, ComponentInfo{com.example/com.example.android.AuthenticatorService}, uid 10028
    D/PackageManager: notifyListener: AuthenticatorDescription {type=com.example.account} is added


    I had the problem that the authenticator xml descriptor referred to a string resource which didn't get resolved properly during the installation:

    android:accountType="@string/account_type"


    The logs showed

    encountered new type: ServiceInfo: AuthenticatorDescription {type=@2131231194}, ...


    Replacing it with a normal string (not resource) solved the problem. This seems to be Android 2.1 specific.

    android:accountType="com.example.account"

    ReplyDelete
  3. Also,

    Check to see if you are treating the AccountType too much like a plain-old-String.

    I have most of my code packaged under com.mycompany.android

    I have been using the following AccountType with success: com.mycompany.android.ACCOUNT.

    Now I have a desire to use multiple accounts, and when I try the approach of appending ".subType" on the end of my account, it fails with the


    caller uid xxxxx is different than the authenticator's uid


    However, if I use "_subType" ( underscore instead of dot ), it works fine.

    My guess is that somewhere under the hood Android is trying to treat com.mycompany.android.ACCOUNT as a legal package name, which it most certainly is not.

    So, again:

    BAD com.mycompany.android.ACCOUNT.subType

    GOOD com.mycompany.android.ACCOUNT_subType

    ReplyDelete