通話記録が空です、Bluetooth再起動をトリガー
誰もが空の電話レコードに不思議に思うだろうと思いますが、今日は、空の電話レコードによって引き起こされるBluetoothクラッシュの元々の問題を皆さんと共有します。
空の電話レコードの生成：今日の社会では、個人情報が空を飛び回っています。関係者がネットワークダイヤルアップソフトウェアを使用して電話にダイヤルすると、空の電話レコードが携帯電話に生成されます。
Bluetooth再起動のトリガーとは、PBAPプロトコルのPCE側でのBluetoothプロセスのクラッシュを指し、これにより、自動Bluetooth再起動の問題が発生します。追跡および分析後、問題の根本的な原因は主にCallLogPullRequest.updateTimesContacted（）にあります。このメソッドは、コールログ内の同じ連絡先のコール数をカウントし、それをアドレス帳データベースに同期するために使用されます。
updateTimesContacted（）はandroid-9の新しいメソッドであるため、この問題はandroid-8以下では発生せず、android-9以降でのみ発生します。
空の通話レコードはどのようにしてBluetoothの再起動を段階的にトリガーしましたか？言うまでもありませんが、同期された通話履歴データ分析プロセスに直接進んでください。
PCE側のBluetoothプロトコルスタックは、通話記録データを受信します。
受信した通話ログVCARDの電話番号情報がHCIレイヤーに異常に表示される実際、通話ログはこの記事で説明した空の通話ログです。携帯電話（PSE）は、通話記録データを組み立てるときに、Bluetooth経由で通話記録データをリクエスタに送信します。番号が存在しないため、「不明な番号」または「番号なし」の文字列は、UTF-8エンコード形式で対応するデータに変換されて送信されますPCEへ。
上図でPCEが受信する電話番号データは、0xE69CAAE79FA5E58FB7E7A081です。
UTF-8エンコード後に対応する文字列に変換：不明な番号
データがVCardEntry.addPhone（）を通過して電話番号を追加すると、char文字が順番に抽出され、文字が標準を満たすかどうかが判断されます。これは「不明な番号」文字列から変換されたデータであるため、ビルダーが最後に空の文字列であることは明らかなので、最後に追加された電話番号データはnull値です。
すべての通話ログデータが分析された後、BluetoothプロセスはCallLogPullRequest.onPullComplete（）を介して通話ログをデータベースに書き込み、各電話番号の通話数をカウントします。データベースを書き込んだ後、最後の呼び出しレコードのタイプがOUTGOING_TYPE（発信タイプ）かどうかを判別し、アドレス帳の連絡先の数を更新します。（呼び出しタイプを判断するこのロジックは不必要に感じられます...）
上記の条件が満たされると、空の電話番号を使用してupdateTimesContacted（）メソッドでデータベースにクエリが行われ、連絡先の数が更新され、IllegalArgumentExceptionパラメータエラーがトリガーされ、Bluetoothプロセスクラッシュがトリガーされます。
問題の根本的な原因の分析はここで非常に明確です。android-9以上のソースコードでこのような問題を回避するための解決策は簡単です。最初にキー値（対応する（電話番号に）空白処理を追加。
興味のある友達はプライベートメッセージを歓迎し、メッセージを残して一緒に話し合い、一緒に学び、一緒に進歩します！
その他の相互接続テクノロジーについては、WeChatパブリックアカウントに注意してください。
