Uso del URI de contenido con ACTION_VIDEO_CAPTURE

Actualmente estoy usando URI de contenido en mi proveedor de archivos para recuperar las imágenes de cámara devueltas por una intención de ACTION_IMAGE_CAPTURE . Esto funciona bien.

Por alguna extraña razón, la misma llamada no funciona al intentar recuperar un archivo de vídeo de la cámara.

  destinationFile = File.createTempFile("video", ".mp4", this.getFilesDir()); Uri uri = FileProvider.getUriForFile(this, getPackageName() + ".fileprovider", destinationFile); Intent cameraIntent = new Intent(MediaStore.ACTION_VIDEO_CAPTURE); cameraIntent.addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION); cameraIntent.setClipData(ClipData.newRawUri(null, uri)); cameraIntent.putExtra(MediaStore.EXTRA_OUTPUT, uri); startActivityForResult(cameraIntent, ID);

Cuando la intención regresa en onActivityResult() el onActivityResult() destinationFile está vacío.

Simplemente reemplazar MediaStore.ACTION_VIDEO_CAPTURE por MediaStore.ACTION_IMAGE_CAPTURE me da el comportamiento esperado: La imagen capturada se guarda en destinationFile.

Esto ocurre en Android 6.0.1 de stock en un dispositivo Nexus y la aplicación de cámara de Google por defecto.

¿Los URIs de contenido realmente no son compatibles con la captura de video? Preferiría no usar un archivo URI en un directorio accesible públicamente.

Tienes dos problemas distintos: el comportamiento de la aplicación de cámara de Google y el comportamiento en todo el ecosistema de Android.

Con respecto a la aplicación de cámara de Google, informamos esto como un error con respecto a Android N , ya que no tienes otra opción que usar un content Uri (si tu targetSdkVersion es N o superior). Se debe arreglar en las próximas versiones.

Dicho esto, no me sorprendería si otras aplicaciones de cámara tuvieran problemas con los valores de Uri content . Esta es una de las preocupaciones que tengo con Android N que prohíbe efectivamente el esquema de file , ya que vamos a encontrar situaciones en las que ni el file ni el content son confiables, y no tenemos una buena manera de detectar estos casos.