AssertionError on some devices in non-primitive Adapter.

[NightlyNexus]

I've got about 20 distinct-device reports from Crashlytics that show an AssertionError in my StringAdapter.
The only way that could happen is if the device has a broken implementation of SharedPreferences.contains() or Editor.delete().

Crashlytics shows about a third of the devices as rooted (honestly not sure if Crashlytics just does a Runtime.getRuntime().exec("su") or what), so I'm guessing 100% of them are using broken firmware.

I'm closing these crash reports with prejudice, but has anybody observed this behavior?
I'm just hoping there isn't some Samsung phone that legitimately shipped with broken firmware that merits a workaround.

[f2prateek]

Could it also be a race - if you delete a preference between the contains check in RealPreference and get call in the adapter?

[NightlyNexus]

Good thought!
In this case, I'm only using the Preference on one thread, though, so these errors are something else, sadly.

But, still, should RealPreference lock there?

[NightlyNexus]

I found my original problem.
I was reusing a key from before I was using rx-preferences.
There was code doing Editor.putString(key, null), and old versions of Android did not delete the preference then. Fixed here: https://android-review.googlesource.com/74070

So, contains() was true, and getString() was null for those broken devices.