Consider replacing regex overrides with FQCNs in the map.

[JakeWharton]

This would allow doing stuff like:

"android.telephony": { .. },
"android.telephony.gsm.SmsManager": { .. },
"android.telephony.gsm.SmsMessage": { .. },

to solve #50, for example, as well as #44 and all the existing cases handled by regex.

[JakeWharton]

I'm doing this here JakeWharton/SdkSearch@6048d43...4d08355 and it's working well.

[romannurik]

I'd love to accept a PR that rethinks how the mapping works, and better yet, shares a mapping with your SdkSearch project :) As a side note, I regret not writing unit tests for the mapping :-/

[JakeWharton]

I'll see if I can come up with something that works and allows both projects to remain in sync relatively easily.

shares a mapping with your SdkSearch project

Long term I want to make SdkSearch a Kotlin multi-platform project and eat your extension so that they can share sync-ing, searching, and source-mapping, but that's a really long-term plan.

regret not writing unit tests for the mapping

I wrote a helper which enumerates all known classes and does an HTTP HEAD request to the source URL to find whether it's valid or not. It's works great (aside from the sleeps to avoid rate limiting).