Search code examples
androidcameravideo-capturemediastoreandroid-fileprovider

Using Content URI with ACTION_VIDEO_CAPTURE

I'm currently using Content URIs on my file provider to retrieve camera images returned by a ACTION_IMAGE_CAPTURE intent. This works fine.

For some strange reason, the same call doesn't work when attempting to retrieve a video file from the camera.

        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);

When the intent returns in onActivityResult() the destinationFile is empty.

Simply replacing MediaStore.ACTION_VIDEO_CAPTURE by MediaStore.ACTION_IMAGE_CAPTURE gives me the expected behavior: The captured image is saved in destinationFile.

This happens on stock Android 6.0.1 on a Nexus device and the default Google camera app.

Are content URIs really not supported for video capture? I'd prefer rather not to use a file URI in a publicly accessible directory.

Solution

  • You have two separate issues: the behavior of the Google camera app and behavior across the whole Android ecosystem.

    With respect to the Google camera app, we reported this as a bug with respect to Android N, since there you have no choice but to use a content Uri (if your targetSdkVersion is N or higher). It should be fixed in upcoming releases.

    That being said, I would not be the least bit surprised if other camera apps encounter problems with content Uri values. This is one of the concerns that I have with Android N effectively banning the file scheme, as we are going to run into situations where neither file nor content are reliable, and we have no good way of detecting these cases.