1

私のコードは、FileObserverを使用してDCIMフォルダーをリッスンします。

私が使用したすべてのAndroidバージョンは、4.1.1を除いて、ビデオの撮影が終了したときに1つのイベントのみを送信しました。これは正しい動作だと思います。継続的に書き込み、終了したら閉じます。

ただし、4.1.1（GalaxyNexusおよびNexusS）では、イベントFileObserver.CLOSE_WRITEが2回送信され ます。つまり、ビデオの開始時と終了時です。

写真についても同じです-イベントは2回送信されます-それほど重要ではありませんが。

問題は、ビデオの開始イベントと終了イベントを区別できないことです。

ファイルのサイズを確認することはできますが、イベントが遅れている可能性があるため（デバイスが遅い/ビジー状態）、サイズがかなり大きい可能性があります。

なぜ振る舞いが変わったのか、何か考えはありますか？カメラのアプリのソースコードがどこにあるか知っていますか？私はそれを理解するために歴史を見てみることができます。

4

2 に答える 2

0

コメントの1つに書いたように、4.1と以前のAndroidバージョンの違いは、4.1.1では、ファイルが2回書き込まれて閉じられることです。空のビデオファイルが作成されたとき。次に、ビデオがtmpファイルに書き込まれます。次に、tmpファイルの名前変更/コピーは2番目のwrite_closeイベントです。

以前のバージョンでは、tmpファイルはなく、元のファイルのみであるため、close_writeイベントは1つだけです。

バグだと思われる場合はコメントしてください。わからない。

于 2012-08-17T06:52:44.743 に答える
0

私は、FileObserverを介してDCIM/Cameraディレクトリを監視するアプリを持っています。私が気付いたのは、最初の操作がCLOSE_WRITEであるということですが、最後の操作は.tmpから実際のファイルへのMOVED_TOです。これは、ビデオの準備ができたことを認識できることを意味します。 。

私の実際のコードは、アプリの要件のためにもっと複雑ですが、一般的な考え方は次のようなものです。

/* My FileObserver implementation field */
private HashSet<String> jbCache = new HashSet(...)

...

protected void onEvent(int event, String path) {
   boolean isJellyBean = Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLYBEAN;

   if ((event & FileObserver.CLOSE_WRITE) > 0) {
      if (isJellyBean) {
         jbCache.add(path);
      } else {
         performYourWork(path);
      }
   } else if ((event & FileObserver.MOVED_TO) > 0 && isJellyBean && jbCache.contains(path)) {
      performYourWork(path);
      jbCache.remove(path);
   }
}

明らかに、キャッチしたいイベントを登録するときは、CLOSE_WRITEとMOVED_TOの両方をリッスンする必要があります。

私はあなたのバグにスターを付けましたが、変更の背後にいくつかの（不快な）理由があるように見えるので、Googleがそれを認めることはないと思います。とにかく、カメラアプリはほとんど標準的ではありません（例：偽のDCIM標準準拠）

于 2013-01-04T22:02:04.473 に答える