本文详细介绍了Android Bluetooth OPP（Object Push Profile）在发送文件过程中的工作流程，从主动连接到文件发送完成后的断开步骤。关键点在于发送完成后调用`BluetoothOppObexClientSession`的`disconnect`方法，关闭socket连接。通过理解这一流程，可以成功移植Android原生的BT OPP功能，实现与原生行为一致的OPP操作。
问题点21: Android Bluetooth的OPPC主动发送完成后，自行断开的flow；
OPP 传送，一般是OPPC 发送文件前主动连接，文件发送完成后，主动断开；
基于Android BT的实际测试Log，发送完成时的明显log是：
“receive MSG_SHARE_COMPLETE for info”，Code位置在类BluetoothOppTransfer的
“case BluetoothOppObexSession.MSG_SHARE_COMPLETE:”中；
-->在类BluetoothOppObexClientSession的内部线程的中执行disconnect；
当前线程一直存在于整个发送过程中，此线程的进入和退出对应的log如下：
“acquire partial WakeLock”和“release partial WakeLock”
-->执行类BluetoothOppObexClientSession中的disconnect方法，里面将执行socket等close动作；
对应log “OBEX session disconnected”，
Note：“mCs.disconnect(null);”中将执行
“sendRequest(ObexHelper.OBEX_OPCODE_DISCONNECT”
至此，关于Android Bluetooth OPP的常用操作以及Source Code逻辑的运行flow描述基本完结。理清Android OPP 中的整运行flow，就可以自行移植，笔者就移植了其实现，移植后OPP的操作与Android 原生BT OPP 无异；
扫一扫
819
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
