Android Bluetooth OPP的理解与使用之五

问题点11：当手机发送文件时，车机会弹出提示菜单，其实现flow是；

----实测发现，当demo车机显示是否接受或拒绝OPP时，其已经收到了第一包

OBEX_OPCODE_PUT进而触发onPut；

-->当操作Demo 车机UI选择拒接时，车机出现的第一个log是：

BluetoothOppReceiver: Receiver ACTION_DECLINE

 通过反推确认” Constants.ACTION_DECLINE”具体的发送者是方法

updateIncomingFileConfirmNotification(参考问题点10，查看此API的执行flow)

Attention：这个方法实现了系统级的Nitofication，当点击”DECLINE” 或”ACCEPT”时，其会对应的发出广播” Constants.ACTION_DECLINE”或Constants.ACTION_ACCEPT；

问题点12：local device OPP Server在点击确认接收文件后, 车机会显示文件接收进度；

 ----核心实现API是：updateActiveNotification；显示进度条的实现是setProgress

 延伸问题点：接收进度条与BluetoothOppObexServerSession的方法onPut关系；

---通过实测发现，进度条的进度显示并不是随着onPut的周期调用而变化；

如当前车机从OPPO 手机端接收一张1,35MB的图片；

其实际应该是：onPut先把data接收完成并通过

” getContentResolver().insert(BluetoothShare.CONTENT_URI”写入了URI中；然后在监听线程BluetoothShareContentObserver中的方法onChange执行updateNotification 发出

NOTIFY；最后在updateActiveNotification中周期读取BluetoothShare.CONTENT_URI中的内容；

 问题点13：local device 当文件接收完成时，在屏幕最底下显示文件接收完成及具体的存储路径；

 --核心API：updateCompletedNotification，通过Notification发出系统通知，只看到了显示接收完成的Toast通知(如上图)；

需注意的是：此API 也负责主动发送完成时的系统通知；

实测log显示：此API执行会比较频繁，其通过API 内部的outboundNum和inboundNum来管控是否发出系统通知；

延伸问题点：显示接收完成的Toast是在哪里发出的；

---基于显示特定格式“Bluetooth share: Received”， 我们找到其对应的资源为

“R.string.notification_received”

 Code 中tracing 发现其实在收到广播

“BluetoothShare.TRANSFER_COMPLETED_ACTION” 后进行的发出；

-->倒推广播BluetoothShare.TRANSFER_COMPLETED_ACTION的发送；

-->sendIntentIfCompleted 发出广播；

-->updateShareStatus中执行sendIntentIfCompleted； 

 -->类BluetoothOppObexServerSession中方法onPut中(第二位置)执行updateShareStatus；

 延伸问题点：如截图所示，当OPP 文档接收完成时，本地存储路径是如何确定的；

 --> else if (action.equals(BluetoothShare.TRANSFER_COMPLETED_ACTION))

如截图，其本地路径是“transInfo.mFileName”栏位，

其通过“BluetoothOppUtility.queryRecord”的静态方法获取到

-->BluetoothOppUtility.queryRecord

 -->执行到BluetoothOppUtility的静态方法fillRecord，进行内容填充；

对应的log打印是“Get data from db:”

 通过实际log反向追溯，发现第一个出现以上路径的log是“Generated received filename”

-->通过“Generated received filename”定位到类BluetoothOppReceiveFileInfo中方法

generateFileInfo；

 通过“filename = base.getPath() + File.separator + filename;”得到全路径名称，然后通过方法chooseUniquefilename来确认当前名称唯一(如之前已有相同名称，则后缀+序号)；最终更新文件名称到“BluetoothShare.FILENAME_HINT”栏位，同时generateFileInfo返回一个带全路径名称；

-->当前generateFileInfo是在BluetoothOppObexServerSession的方法processShareInfo中被调用；

-->倒推到BluetoothOppObexServerSession中方法addShare调用processShareInfo；

对应log是：“addShare for id”

 Note：此时全路径资讯被赋值到类BluetoothOppObexServerSession 的mFileInfo中；

-->倒推到类BluetoothOppTransfer中方法processCurrentShare调用addShare；

-->通过实际log倒推到类BluetoothOppTransfer中方法 startObexSession中调用processCurrentShare；

-->通过Log “Create handler thread for batch”倒推到BluetoothOppTransfer中方法start执行startObexSession；

 -->通过log “Service start server transfer new Batch”倒推到类BluetoothOppService中方法insertShare执行的“mServerTransfer.start();”

 所以实现全路径名称问询的起始在方法insertShare；