一：Background & 有关flow
MTK Operator name display分为两种类型的手机：
1. Sim卡名称：
从基于引导SIM卡读取IMSI到Spn-conf.xml在(假设MVNO该卡是Virtual-spn-conf-by-***.xml中)匹配得到的name，会保存在SIMInfo这个database中，兴许sim卡的名称就从此database中取得
关于MVNO能够參考例如以下FAQ:
ID: FAQ09811
[NW]怎样区分MNO和MVNO
使用场景：
Setting下SimMangement中SIMInfo等
2. 注冊上的网络的名称：
这部分显示所用string的主要来源有例如以下这些。且他们之间终于显示哪个source的string是依据网络和这些source的内容所终于确定的rule决定的（如当前是否roaming，当前注冊的plmn是否在EF_SPDI中，EF_SPN中有相关flag标识要不要显示spn…）
关于rule：
请參考Gsm sec 51.011 EF_SPN的部分还有cphs spec。
code的部分，请參考SIMRecords. getDisplayRule和GsmServiceStateTracker. updateSpnDisplay：
(1) Sim卡中文件。如EF_SPN, EF_OPN, EF_SOPN, EF_OPL, EF_PNN, EF_SPDI…
(2) 注冊到的网络的plmn，相应Spn-conf.xml
(3) NITZ，即网络下发的名字
Spec 51.011中EF_SPN定义的rule 总结就是：
1. 名称分为 SPN 和 Registered plmn（包含EONS, CPHS (即ONS), S-CPHS, NITZ, PLMN。优先级依次减少）
2. 假设没有SPN文件，那么就显示Registered plmn
3. 若有SPN，注冊的plmn是HPLMN或者注冊的plmn在SIM卡文件EF_SPDI中，那么
(1) 假设有SPN就要显示SPN
(2) 假设SPN的bit1 = 1, 则须要同一时候显示Registered plmn，假设SPN的bit1=0，则不须要同一时候显示Registered plmn
4. 若有SPN，注冊的plmn是Roaming plmn且注冊的plmn也不在SIM卡文件EF_SPDI中，那么
(1) 显示Registered plmn
(2) 假设SPN的bit2=0，则须要同一时候显示SPN，假设SPN的bit2=1，则不须要同一时候显示SPN
当中客户能够客制化的部分是Spn-conf.xml/Virtual-spn-conf-by-***.xml；换句话说，假设你改动了相关xml没有生效，应该是依照spec显示了更高优先级的名字（EONS, CPHS, NITZ…）
假设依照spec显示了更高优先级的名字，而不是xml配置的，那么想要显示xml的名字必定要改动code flow而导致破坏spec定义的rule（因为这是spec定义的通用rule，所以SIM卡在实做时也须要follow spec rule）------这种客制化非常可能会导致CTA/FTA等測试fail，且遵循spec的SIM卡显示也会出问题；建议跟客户说明这部分是有spec规定的，不要进行除xml的客制化
二：遇到问题时的处理方式
假设有些Operator不follow GSM Spec，而定义自己的rule，请遵循的例子中，以下列方式：
（1）假设operator有正式spec，请提供具体的技术文件。
（2）把这张卡在同一时间和地点（另外，还要确保网络状态）放Samsung，HTC和其他控制设备来重现问题，提供控制机器性能
（3）这个地方卡MTK手机重现该问题，并提供电源来重现问题mobile log
MTK Operator name display分为两种类型的手机：
1. Sim卡名称：
从基于引导SIM卡读取IMSI到Spn-conf.xml在(假设MVNO该卡是Virtual-spn-conf-by-***.xml中)匹配得到的name，会保存在SIMInfo这个database中，兴许sim卡的名称就从此database中取得
关于MVNO能够參考例如以下FAQ:
ID: FAQ09811
[NW]怎样区分MNO和MVNO
使用场景：
Setting下SimMangement中SIMInfo等
2. 注冊上的网络的名称：
这部分显示所用string的主要来源有例如以下这些。且他们之间终于显示哪个source的string是依据网络和这些source的内容所终于确定的rule决定的（如当前是否roaming，当前注冊的plmn是否在EF_SPDI中，EF_SPN中有相关flag标识要不要显示spn…）
关于rule：
请參考Gsm sec 51.011 EF_SPN的部分还有cphs spec。
code的部分，请參考SIMRecords. getDisplayRule和GsmServiceStateTracker. updateSpnDisplay：
(1) Sim卡中文件。如EF_SPN, EF_OPN, EF_SOPN, EF_OPL, EF_PNN, EF_SPDI…
(2) 注冊到的网络的plmn，相应Spn-conf.xml
(3) NITZ，即网络下发的名字
Spec 51.011中EF_SPN定义的rule 总结就是：
1. 名称分为 SPN 和 Registered plmn（包含EONS, CPHS (即ONS), S-CPHS, NITZ, PLMN。优先级依次减少）
2. 假设没有SPN文件，那么就显示Registered plmn
3. 若有SPN，注冊的plmn是HPLMN或者注冊的plmn在SIM卡文件EF_SPDI中，那么
(1) 假设有SPN就要显示SPN
(2) 假设SPN的bit1 = 1, 则须要同一时候显示Registered plmn，假设SPN的bit1=0，则不须要同一时候显示Registered plmn
4. 若有SPN，注冊的plmn是Roaming plmn且注冊的plmn也不在SIM卡文件EF_SPDI中，那么
(1) 显示Registered plmn
(2) 假设SPN的bit2=0，则须要同一时候显示SPN，假设SPN的bit2=1，则不须要同一时候显示SPN
当中客户能够客制化的部分是Spn-conf.xml/Virtual-spn-conf-by-***.xml；换句话说，假设你改动了相关xml没有生效，应该是依照spec显示了更高优先级的名字（EONS, CPHS, NITZ…）
假设依照spec显示了更高优先级的名字，而不是xml配置的，那么想要显示xml的名字必定要改动code flow而导致破坏spec定义的rule（因为这是spec定义的通用rule，所以SIM卡在实做时也须要follow spec rule）------这种客制化非常可能会导致CTA/FTA等測试fail，且遵循spec的SIM卡显示也会出问题；建议跟客户说明这部分是有spec规定的，不要进行除xml的客制化
二：遇到问题时的处理方式
假设有些Operator不follow GSM Spec，而定义自己的rule，请遵循的例子中，以下列方式：
（1）假设operator有正式spec，请提供具体的技术文件。
（2）把这张卡在同一时间和地点（另外，还要确保网络状态）放Samsung，HTC和其他控制设备来重现问题，提供控制机器性能
（3）这个地方卡MTK手机重现该问题，并提供电源来重现问题mobile log