Android R 又对 Tap&pay菜单 进行了更新，变得更加合理化，人性化了。
(编辑于2020-4-20 12:24:10）
Android R Tap&pay菜单
如图可知，路径变更为 Settings -> connected devices -> Conncetion preferences -> NFC ->Contactless payments。也不叫Tap & pay菜单， 而直接叫Contactless preference.
Android O Tap&pay菜单
(编辑于2017-10-19 14:57:10）
Android M和N的Settings应用主界面布局，没有太大的变化，但是在实现方式上已经有些差别。
但是到了O版本，实现方式和N 接近，但是分类各菜单的归类已经有了很大差异。
下面来看看Android O在真机中的表现。
从Settings主界面来看，O不再有device,personal,system等分组了，而每个菜单项即其子菜单项的分组。
那么问题来了，由于项目NFC模块尚未合成，导致NfcAdapter无法获取实例，导致NFC相关的菜单项被隐藏，
那么这些相关项又被挪到了哪里呢？
首先，根据相关类名寻Manifest，得如下信息。
据以往项目N/M中,PaymentSettings即用来管理支付应用的一个菜单菜单都应的界面，那么它依附于谁呢。
据搜索结果可知，其依附于DefaultAppsSettings这个界面中的某个菜单项，其它的类都不是，DefaultPaymentSettingsPreferenceController是用来控制PaymentSettings显示。
再瞅瞅DefaultAppsSettings实现，其布局可查app_default_settings.xml。
getPreferenceScreenResId方法获取到界面布局资源文件，在本Fragment(DefaultAppSettings)创建onCreate时调用。
而getPreferenceControllers方法则在Fragment被附在Activity上时调用，并在DefaultAppSettings的父类DashboardFragment中有个成员用来存储获取到的PreferenceControllers。
@Override
public void onAttach(Context context) {
super.onAttach(context);
mDashboardFeatureProvider =
FeatureFactory.getFactory(context).getDashboardFeatureProvider(context);
mProgressiveDisclosureMixin = mDashboardFeatureProvider
.getProgressiveDisclosureMixin(context, this, getArguments());
getLifecycle().addObserver(mProgressiveDisclosureMixin);
List<AbstractPreferenceController> controllers = getPreferenceControllers(context);///
if (controllers == null) {
controllers = new ArrayList<>();
}
mPlaceholderPreferenceController =
new DashboardTilePlaceholderPreferenceController(context);
controllers.add(mPlaceholderPreferenceController);
for (AbstractPreferenceController controller : controllers) {
addPreferenceController(controller);///
}
}
protected void addPreferenceController(AbstractPreferenceController controller) {
mPreferenceControllers.put(controller.getClass(), controller);
}也就是说，这些controller是在DefaultAppSettings的onCreate()方法之前，已经被map对象持有了。
下面看看打印的大致log。
不管subSettings对应的哪个Fragment，无论是AppAndNotificationDashboardFragment还是DefaultAppSettings，都是集成自DashboardFragment,所有log均加在DashboardFragment，基本每个Fragment的生命周期看它即可，具体到某个Fragment，只需要提供之间的区别点即可，例如：布局文件，类似与Settings Activity的处理方式。
由以上log可知，
onAttach()在onCreate()之前即已被执行，即在onCreate()时已持有布局中各菜单项对应的各controllers对象引用。
由此，Fragment各生命周期中均可根据controller的控制消息来决定显示与否。
下面来看个比较另类的简图。
由中轴线而分，左边为Fragment生命周期中重要的几个方法调用，右边为controller所能提供的信息，Fragment生命周期中合理地使用controller提供的信息来描绘perferenceKey对应的perference行为表现。
最后，强行修改controller中提供的isAvailable()，让显示隐藏的tap & pay菜单，并通过updateState()更新对应的summary，给出一个test 效果。
截图如下：
图中图标和summary为强制更改controller的updateState()方法中进行设置的。
