In addition to that, I don’t understand the “endless loop issue”. As I understand, the photo that is resized by android would be synced back to the server which just stores the resized version. If the server won’t touch the photo again, the circle would end here, wouldn’t it?
- The high-res photo >1MB is downloaded from the server and parsed by ez-vcard, which returns a
byte[]
.
- This large
byte[]
can’t be stored into the contact’s thumbnail BLOB (transaction too large).
- So, the photo must be written as a file using the ContactsContract.RawContacts.DisplayPhoto CONTENT_DIRECTORY.
3a. In order to write this file, we need a raw contact ID before, so the INSERT has to be done before and
3b. in a second pass, the photo file for this raw contact ID will be written.
- Sync is now complete, the contact’s DIRTY flag is removed.
But: 3b is not blocking, so Android modifies the photo in the background and after a few seconds, when step 4 is already finished, it writes the modified (resized etc.) photo for the contact and marks the contact as dirty again.
So, at the next sync, the contact is dirty and it will all start from 1…
Normally, there’s a “IsSyncAdater” that can be set and that should prevent marking records as DIRTY when changing them, but this doesn’t seem to work for the photo-writing class.
I suppose, the 1MB limit can’t be adjusted anywhere, can it?
Exactly
As far as I have understood it, the limit is hard-coded.