>> Not entirely sure how this made front page, but it is a super handy lib.
Sad that nowadays a statement like that isn't even considered ironic :). A cross-platform library handling an ugly necessity of development has to fight for its life in a sea of "growth hacking 101" links and the like.
That's true, I totally agree with you at its irony in hindsight. I guess I'm a bit blinded at having worked on Android apps for a while and using this lib way too often.
I would speculate that the reason why is so that Google doesn't have to maintain several versions of the library within the Android platform.
If Google is the only consumer, then Google only has to test internally that they didn't break something with an update. If tons of apps are consumers then they need to either test with many more apps, or worse just simulate buggy old behaviour for apps to keep things consistent (see Windows/Win32/etc).
If apps house their own copy of the library, then that version is static for that app's context, which likely means it won't break randomly in the future. That's good for the app developer (better back and forward compatibility), better for Google (less testing, less maintaining compatibility), and less headaches for consumers (as apps won't break as often when updating Android).
This reminds me of one of my favourite quotes: "If something in software doesn't make sense, then assume it is there for compatibility reasons." Which I think is a Raymond Chen quote that I've mangled.
I posted it after one of our engineers discovered that this is a hard problem!
We were trying to use Twilio and Authy on an application but they handle phone numbers in a different way. Say you accept a phone number from Argentina, to call mobile phones from outside the country you need to add a 9. Twilio accepts that 9 and correctly sends SMS or calls to that number but Authy only accepts the local number format without the 9 and have a big IF to add the 9 internally. So, if for some reason the application must use a phone number in Twilio AND Authy you will need to accept two phone numbers from the user (that are the same in different formats), which is... annoying.
The reason it's internal is because system code takes priority over third party libraries given the same package name. If there were any changes to the library, you could never use the newest version because it would be dominated by the system version. This is what happened to the Apache HttpClient and why there is a fully repackaged version[1] for people who want to use a newer client than the one in the Android System.
Yeah but it's already namespaced differently so package name shouldn't conflict. But now that I think about it more, consistent versioning for the 3rd party dev across multiple OS versions is pretty important.
I don't understand why Android includes this lib in their source but makes it internal so you have to provide your own copy if you want to use it in your app: https://android.googlesource.com/platform/external/libphonen...