| HN Mirror

Most of them were just half-broken APIs (e.g. some less-used query URIs would just error[1], or had buggy triggers), or only partially-covered indexes (so e.g. the stock app would be able to display conversations quickly, but [your query / 3rd party app] might not), or additional columns or queries (very common, occasionally interesting). A couple had obvious SQL injection bugs (contacts providers sometimes have these too). And most that I looked at were using older versions of the provider than the OS should have had, which is... great. Just great. I don't think fine-grained checks are part of the CTS.

Broken APIs can usually be worked around by doing a couple smaller queries and gluing the data together (often performs better anyway), partially covered indexes often mean the same thing (or just making do with less data in your app). And/or just decompile the stock app and see what it does differently.

SQL injections are fun tho, I managed to use a couple to dump the full databases, or add / repair missing indexes or triggers (never shipped code that did this, but it helped locally! would've probably broken if they ever upgraded the provider version tho). Some phones also try to protect / escalate Facebook data / access, but if there's an injection you can usually change the "protected" marker on its data.

[1]: https://android.googlesource.com/platform/packages/providers...

---

I love that android has these shared providers, they let you do some super interesting and useful things, and for the most part everyone plays nice (but the "social stream" stuff in contacts is... odd, and rare). They seem to get pretty low amounts of attention tho, e.g. the sms provider had a few rounds of "caching bug in stock app" -> "finally make that pk autoincrement so it stops reusing ids" which were painfully obvious from reading the source: https://github.com/aosp-mirror/platform_packages_providers_t... . The current version has most or all of these fixed, but it took a few years to get there.