NFC的一些总结

   NFC--near field communication,一种短范围无线技术集合，通常需要4cm或更短的距离才能初始化连接，允许在nfc标签与安卓设备，或者两个安卓设备之间共享小的数据

   大多数的安卓框架api都使用基于NDEF（nfc data exchange format）标准，ndef数据和安卓一起工作的场景有二：

   其中，应用1的工作流程是这样的：从标签调度系统从nfc标签中读取ndef数据，然后分析标签，对数据进行适当的分类，并启动对该类数据感兴趣的应用程序，这个应用程序需要声明一个intent过滤器去请求处理这个ndef数据

   而应用2是：Android  Beam™ 功能允许设备把一个NDEF消息推送到物理上相互监听的另一个设备上｡这种交互提供了比其他无线技术(如蓝牙)更容易的发送数据的方法｡因为NFC不需要手动的设备发现或配对要求｡两个设备在接近到一定范围时会自动的连接｡Android Beam通过一组NFC API来使用,以便应用程序能够在设备之间来传输信息｡例如,通信录､浏览器以及YouTube等应用程序都使用Android Beam来跟其他设备共享通信录､网页和视频｡发送给另一个设备｡

  再说一下nfc标签调度系统：

  如果nfc没有在设置中被禁用，那么安卓设备会在非锁屏的情况下搜索nfc，当设备发现nfc标签时，理想的情况是直接就调用最适合的activity去处理这个intent，而不会去询问用户选择哪个app来开启，为毛？设备在很短的距离找到了nfc<4cm,一旦你叫用户去选择，就会导致设备离开nfc，就会中断连接，所以为了达成这个理想的情况，安卓就提供了特殊的标签调度系统，它就通过如下这些手段来保证最合适的app去处理nfc信息：

  1.解析nfc标签并搞清楚标签中标识数据负载的MIME类型或则URI

  2.把MIME类型或则URI以及数据负载封装到一个intent中

  3.基于intent来启动activity

  

  下面说下，具体测试中遇到的一些问题归纳：

  1.MTK6595芯片，wifi模块和nfc模块是集成在一起的，在双方手机都关闭wifi时，两台手机靠近时会弹出有可用wifi信号提示，就是开启了wifi，这个开启状态一直持续到文件传输结束，然后wifi关闭

  2.本机在打开wifi并连接热点的时候，靠近对方手机，会断开wifi热点的连接，从这两点的现象看出，mtk的这个模式或者芯片并不太好，我不清楚wifi和nfc模块放一起有什么硬件无线传输上的便利还是什么，但是这种用法感觉并不太好，那时候刚好看到cdmtk找人做nfc测试，后悔没有一试，哇哈哈

  3.说这个芯片不好，还有一个bug：在使用智能标签时，总有一定几率弹出nfc的工厂测试模式，尤其是当对方机器锁屏时，6595机器就弹工厂模式，经我们开发分析是由于nfc的消息传递导致，在双方手机互碰时，有一个消息的传递过程，但是当对方手机锁屏时，这个消息动用了最高级别，我们猜想可能手机的工厂测试模式有一个广播接收器，锁屏时，这个广播接收器也接收了这个最高优先级的信息，这个需要mtk来分析处理

  4.测试一碰即传的时候，最开始我是用的我们测试机与一台一加手机进行的互传，本app可以传输4种格式的文件，视频，音频，名片，图片，在尝试两个名片一起传输时，会crash报不成功，这个原因是因为单个的名片是通过NFC直接进行传输，直接把该名片（数据库中的文件直接）写入对方的联系**p中，这是因为本身名片的体量小，然后两个名片就变得稍微大些，是通过蓝牙进行传输的，所用的方式需要把名片转为实体的VCF文件，在这个转换的时候，开发没有考虑到这种情况，没有做这种转换，所以传输的时候，本手机没有这种处理方式，导致了问题的发生 

  5.有一天，我刚好手边有一台MTK芯片的手机，于是我用这台机器再来验证，却发现连图片也不能传输了，后来再一定位是：图库中或者文件夹中某些文件夹的文件不能传输，发现：都是选择图片 从不同的地方（图库 文件管理器）选择的图片它在系统中的路径形式是不一样的，都是从图库选择图片，你选择照相机和beam里面的，图片路径形式也是不一样的：

 一种是这样的：content://media/external/images/media/43  就没问题，

 另一种是这样的：content://com.android.providers.media.documents/document/image%3A55   这样的就有问题，

  报错信息：

  Permission Denial: opening provider com.android.providers.media.MediaDocumentsProvider from ProcessRecord{42f758e8 1097:com.android.nfc/1027} (pid=1097, uid=1027) requires 

android.permission.MANAGE_DOCUMENTS or android.permission.MANAGE_DOCUMENTS

  log显示这些文件是以content provider的格式来存储使用的，而我们开发只考虑了FILE这种文件格式，没有设置cp的权限，导致了失败，

   

   6.再尝试两个MTK带NFC功能的手机互传时，还是不能成功，而且与之前一加的不同在于，当本机的wifi处于开启并且连接热点的情况下，总是提示断开当前连接，后来发现，这是因为MTK的芯片与高通的不同，可能mtk与高通互联的时候走的是蓝牙，而mtk机器之间走的是wifi直连，所以当一方手机连接了wifi热点的时候，会需要断开当前，而且在对方或者本机没有开启wifi时候，互传时在建立传输时也需要暂时打开双方wifi，传输完成之后wifi关闭。但是即使是弄清楚了这些，我们发现还是存在一些失败的情况，后来我们使用了一台MTK源码的机器，不走我们自己的app，直接通过原始的NFC传输来查看，发现了一个更为严重的问题，就是存在一定概率的死机重启现象，这个问题我们只能抓取通过MTKlogger抓取log，底层的以及上层的，去给MTK的开发分析原因，待续。后来无续了。。。

   在测试这些问题的时候，用MTK的手机进行普通的互传，之前的NFC工厂测试却一直弹出，这肯定了我们之前的猜测，工厂测试的弹出还是底层代码或者方案代码就出了问题，后来还是转MTK提交了这个bug，我们给出具体的包括应用层，底层的log之后，问题得到了解决，由于各个公司的问题，MTK没有告知我们具体的原因，但是我认为我们的推测是对的，这就是MTK底层的问题，和它的蓝牙NFC芯片的一些代码没有耦合好