转载请注明出处：https://blog.csdn.net/turtlejj/article/details/83748519，谢谢～
在做Android P的升级时，遇到了一个问题，Dialer、Contacts、InCallUi等应用，在打开的瞬间就会发生FC。以Contacts为例(由于每家厂商都可能会定制自己的Contacts应用，代码可能与原生Android不同，因此未必能通过我这里的Call Stack从Android原生代码中找到相应的调用)，抓到的log如下：
Caused by: java.lang.RuntimeException: cannot load/parse metadata
at com.android.i18n.phonenumbers.MetadataManager.loadMetadataAndCloseInput(MetadataManager.java:217)
at com.android.i18n.phonenumbers.MetadataManager.getMetadataFromSingleFileName(MetadataManager.java:190)
at com.android.i18n.phonenumbers.MetadataManager.getMetadataFromMultiFilePrefix(MetadataManager.java:116)
at com.android.i18n.phonenumbers.MultiFileMetadataSourceImpl.getMetadataForRegion(MultiFileMetadataSourceImpl.java:64)
at com.android.i18n.phonenumbers.PhoneNumberUtil.getMetadataForRegion(PhoneNumberUtil.java:2212)
at com.android.i18n.phonenumbers.PhoneNumberUtil.getCountryCodeForValidRegion(PhoneNumberUtil.java:2373)
at com.android.i18n.phonenumbers.PhoneNumberUtil.getCountryCodeForRegion(PhoneNumberUtil.java:2361)
at com.android.i18n.phonenumbers.AsYouTypeFormatter.getMetadataForRegion(AsYouTypeFormatter.java:137)
at com.android.i18n.phonenumbers.AsYouTypeFormatter.<init>(AsYouTypeFormatter.java:130)
at com.android.i18n.phonenumbers.PhoneNumberUtil.getAsYouTypeFormatter(PhoneNumberUtil.java:2694)
at android.telephony.PhoneNumberFormattingTextWatcher.<init>(PhoneNumberFormattingTextWatcher.java:71)
at com.android.contacts.compat.ContactPhoneNumberFormattingTextWatcherCompat.newInstance(ContactPhoneNumberFormattingTextWatcherCompat.java:23)
at com.android.contacts.util.PhoneNumberFormatter$TextWatcherLoadAsyncTask.doInBackground(PhoneNumberFormatter.java:48)
at android.os.AsyncTask$2.call(AsyncTask.java:333)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
通过log可以大致推断出，FC是在Contacts对手机号码进行格式化时发生的。
根据Call Stack进行跟踪，发现Contacts调用了framework中PhoneNumberFormattingTextWatcher类的构造方法，而该构造方法中调用了一个叫做PhoneNumberUtil的类中的getAsYouTypeFormatter()方法。
/**
* The formatting is based on the given <code>countryCode</code>.
*
* @param countryCode the ISO 3166-1 two-letter country code that indicates the country/region
* where the phone number is being entered.
*/
public PhoneNumberFormattingTextWatcher(String countryCode) {
if (countryCode == null) throw new IllegalArgumentException();
mFormatter = PhoneNumberUtil.getInstance().getAsYouTypeFormatter(countryCode);
}
根据查找发现，PhoneNumberUtil这个类是在libphonenumber这个模块中的，是一个用于对手机号码进行格式化的开源项目，这种开源项目的代码一般是不会出现问题的。
刚看到这里的时候，我就觉得肯定是我们在给libphonenumber这个模块打Patch的时候出了什么问题。所以，我们就Patch进行了排查，发现确实有同事修改了一个bin文件，该修改是为了解决老版本的Android原生代码不能正确对166和199开头的手机号进行格式化的问题。修改是从Android O上直接cherry过来的。
libphonenumber/src/com/google/i18n/phonenumbers/data/PhoneNumberMetadataProto_CN
然后，我查看了Contacts的mk文件，发现Contacts是静态依赖于libphonenumber的，即Contacts会将libphonenumber的编译产物包进自己的apk当中。
并且，使用apktool工具将Contacts的apk进行反编译后，发现其中确实包含了libphonenumber的产物。
LOCAL_STATIC_JAVA_LIBRARIES := \
android-common \
com.android.vcard \
guava \
libphonenumber
我回退了这个Patch，重新编译了Contacts的apk并push到手机里，心想问题应该不会复现了。但是，出乎意料的时，Contacts还是会发生一模一样的FC问题。
于是，我猜想，问题也许不是由于这个Patch导致的？因此，我在libphonenumber的代码里加了log，想看看到底问题出在哪里？重新编译了Contacts的apk，并push到手机里后，发现新加的log并没有打印出来，而且最令人感到疑惑的是，由于加了log，代码的实际行数发生了变化，但是新抓取的FC log却还是与之前发生在同样的行数。
这让我不由得怀疑，是不是libphonenumber模块在编译Contacts时并没有重新生成，而是使用了原来的编译产物。
接下来，我在libphonenumber的代码中随意加入了一些语法错误，想看看，在编译Contacts的时候，libphonenumber会不会报错。然而，结果是，libphonenumber确实报了编译错误，而且就是由于我加入的语法错误而引起的。
我又用apktool将新编译出来的Contacts进行反编译，发现PhoneNumberMetadataProto_CN文件确实被我回退了，那就说明，libphonenumber的的确确是被编译出来幷包进Contacts的apk中了。
那为什么修改就是不生效呢？没有办法，我只能用Android Studio的单步调试功能，一步一步的跟踪代码的流程(关於单步调试的方法，可以参考《使用Android Studio对Android系统源码进行单步调试》)。
然而就是这次跟踪，让我发现了问题所在。
在跟踪代码到MetadataManager.java中的loadMetadataAndCloseInput(InputStream source)方法时，我发现了一个很奇怪的地方，这里尝试去读的不是Contacts的apk中的PhoneNumberMetadataProto_CN，而是ext.jar中的PhoneNumberMetadataProto_CN。
看到这之后，我猜测，Contacts根本没有读取自己apk中libphonenumber相关的代码与文件，而是去读取了ext.jar中的相应模块。于是我去找了一下frameworks/base/Android.bp文件中ext.jar是如何编译的，果不其然，ext.jar也包含了libphonenumber，但是，其名字却叫libphonenumber-platform。
// Build ext.jar
// ============================================================
java_library {
name: "ext",
no_framework_libs: true,
static_libs: [
"libphonenumber-platform",
"nist-sip",
"tagsoup",
"rappor",
],
dxflags: ["--core-library"],
}
继续查看libphonenumber的Android.bp文件，找到libphonenumber-platform相关的内容，可以看到，有一条jarjar_rules
// For platform use, builds directly against core-libart to avoid circular
// dependencies. *NOT* for unbundled use.
java_library_static {
name: "libphonenumber-platform",
// For the platform, compile everything except the carrier to phone number
// which isn't used.
java_resource_dirs: [
"libphonenumber/src",
"geocoder/src",
"internal/prefixmapper/src",
],
srcs: [
"libphonenumber/src/**/*.java",
"geocoder/src/**/*.java",
"internal/prefixmapper/src/**/*.java",
],
jarjar_rules: "jarjar-rules.txt",
sdk_version: "core_current",
java_version: "1.7",
}
在当前目录下找到jarjar-rules.txt文件，发现这个文件只有一行
rule com.google.** com.android.@1
即，将libphonenumber这个模块中com.google的包名，全部替换为com.android。于是我到libphonenumber和Contacts中的代码里去看了一下，确实如此。
libphonenumber中的代码包名是com.google.i18n.phonenumbers，而Contacts所调用的framework中的PhoneNumberFormattingTextWatcher类在import的时候，全部用的是com.android.i18n.phonenumbers；同样，Call Stack中打印出来的包名也都是com.android.i18n.phonenumbers。
据此，反过来查看libphonenumber的Android.bp中关于libphonenumber的编译信息，发现编译libphonenumber时，是没有替换包名的。
// For unbundled use, supports gingerbread and up.
java_library_static {
name: "libphonenumber",
defaults: ["libphonenumber-unbundled-defaults"],
srcs: ["geocoder/src/**/*.java"],
java_resource_dirs: ["geocoder/src"],
sdk_version: "9",
java_version: "1.7",
}
由此，终于明白，为什么不论如何修改代码重新编译Contacts，FC的Call Stack都不会发生变化了，因为代码调用的一直都是ext.jar中的libphonenumber，而回退Patch并添加log后ext.jar没有重新编译并push到手机里。
回退Patch，重新编译ext.jar，并push到手机中，问题不在复现。
究其原因，是因为Android P和Android O在读取和写入PhoneNumberMetadataProto_CN文件的相关代码发生了变化，不能直接将O上对该文件的修改直接merge到P上(P版本的PhoneNumberMetadataProto_CN文件已经添加了对166以及199开头号码的格式化，因此该Patch也就不需要打了)