1

私のソフトウェアはしばらくの間問題なく動作していましたが、Android 4 ではいくつかの新しい問題が発生しました。

(Android 4.0.4 搭載のデバイス Samsung Note)

以下は、スレッド内/スレッド上のループ内で実行されます

try {
    socket.connect();     // <-- this blocks for up to 6 sec

} catch (IOException e) { // <-- this was entered
    try {
        socket.close();   // <-- here the NPE happened
    } catch (IOException ioe) {
        //stuff
    }

} catch (NullPointerException npe) {
    //stuff
}

接続のブロック中にソケットが null になる可能性があるという経験をしましたが、最近、IOEx catch ブロック内で null であることをキャッチしました。そのため、接続は NPE ではなく IOEx をスローしたため、ソケットはまだそこにありました。catch ブロック内で、socket.close() が NPE をスローしてサービスをクラッシュさせました。これは、そこで NPE キャッチを使用しなかったためです。

そもそもオブジェクトが生きている必要がある別のcatchブロック内にNPE catchブロックを配置するのは意味がありません。

これはすべて、Android 4 でますます多く発生しており、ほとんどの場合、サービス (およびアプリ) がしばらくの間バックグラウンドで実行されています。マーケットアプリではないので、ホームボタンを押しても起動していれば問題ありません。しかし、バックグラウンドが長すぎると、(接続されていない!) ソケットが gc されているようです。

質問は: なぜこれが起こっているのですか? 内部 IOEx に加えて NPE キャッチを本当に配置する必要がありますか?

4

1 に答える 1

1

Bluetooth での Android ICS にも問題があることに気付きました。彼らが主張するように、Android ICS は Bluetooth にいくつかのセキュリティ バグ修正を導入しました (さらに多くのバグもありました)。

そのため、Androidバグトラッカーで報告します。他のデバイスをチェックして、それが Samsung の Bluetooth スタックなのか、Android コードなのかを確認することが重要な場合があります。

ペアリングに問題がありましたが、Android Bugtracker で報告された問題を確認することも関連している可能性があります..

于 2012-11-22T11:00:58.310 に答える