Address books are no longer properly deleted



  • Hi,

    I noticed a strange problem after upgrading from 2.3 to 2.5.1.
    In my case, I have an account with multiple address books (and no calendars).
    To reproduce the problem, I do the following step:

    • setup an account with multiple address books
    • select all the address books and hit sync -> all contacts are synced properly
    • deselect all address books and hit sync -> address books and contacts are removed from the contacts app
    • select all address books again and hit sync -> not all contacts are synchronized anymore. Instead I get exceptions like this in the logcat output:
    06-19 16:38:01.782 5191-5324/at.bitfire.davdroid E/davx5: [syncadapter.AddressBooksSyncAdapterService] Couldn't sync address books
        EXCEPTION java.lang.IllegalStateException: Address book doesn't exist anymore
            at at.bitfire.davdroid.resource.LocalAddressBook.getMainAccount(LocalAddressBook.kt:133)
            at at.bitfire.davdroid.resource.LocalAddressBook$Companion.findAll(LocalAddressBook.kt:73)
            at at.bitfire.davdroid.syncadapter.AddressBooksSyncAdapterService$AddressBooksSyncAdapter.updateLocalAddressBooks(AddressBooksSyncAdapterService.kt:95)
            at at.bitfire.davdroid.syncadapter.AddressBooksSyncAdapterService$AddressBooksSyncAdapter.sync(AddressBooksSyncAdapterService.kt:48)
            at at.bitfire.davdroid.syncadapter.SyncAdapterService$SyncAdapter.onPerformSync(SyncAdapterService.kt:73)
            at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)
    

    and also

    06-19 16:32:27.736 5191-5300/at.bitfire.davdroid E/davx5: [syncadapter.ContactsSyncAdapterService] Couldn't sync contacts
        EXCEPTION java.lang.IllegalStateException: Address book doesn't exist anymore
            at at.bitfire.davdroid.resource.LocalAddressBook.getMainAccount(LocalAddressBook.kt:133)
            at at.bitfire.davdroid.syncadapter.ContactsSyncAdapterService$ContactsSyncAdapter.sync(ContactsSyncAdapterService.kt:39)
            at at.bitfire.davdroid.syncadapter.SyncAdapterService$SyncAdapter.onPerformSync(SyncAdapterService.kt:73)
            at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)
    

    I can reproduce this problem on Android 4.5 and 5.1, 9.0 seems to work fine.
    Might the switch to jetpack/room be relevant here?



  • Also, if I remove the account, not all related address books account are deleted along with it. It seems that (some of) the address book accounts have a broken reference to the main account.



  • In my test case, I have two address books. Attached is the debug output
    davx5-info.txt



  • I did test with various Android VMs. The preliminary results look like this:

    4.4: affected
    5.1: affected
    6.0: affected
    7.1: not affected
    8.1: not affected
    9.0: not affected



  • The 4.4, 5.1 and 6.0 VMs did not have the Google Playstore APIs installed. Not sure if this is relevant.


  • developer

    Thanks for the report, I can confirm this grotesque behavior. It seems like Android’s AccountManager doesn’t store the initial user data in all cases (only happens sometimes), so the address book accounts can’t store their main account anymore.

    Are you absolutely sure that this is related to DAVx⁵ 2.5? As I understand it, this problem should have been problem in previous versions, too.

    When the initial user data is explictly set a second time after creating the account, it seems to work here. Can you test that? Shall I send an .apk or can you test from master source code?



  • A separate branch would be fine.
    As for 2.3: I’ve never seen this behaviour with that version, but if it’s a race maybe I was just lucky enough to not trigger it.
    I can rather reliably reproduce it with 2.5.1 in the emulator and I fail to do so with 2.3



  • Seems you already have committed a fix to master (the email I got still talked about creating a branch).
    Will test that and report back.


Log in to reply
 

Similar topics

  • 3
  • 1
  • 5