So, I've come to find that the method of starting a camera intent provided by:
http://developer.android.com/training/camera/photobasics.html
Will eventually fail if you take a photo, and then hit cancel multiple times. I've tried it on other apps than the one I'm building and sure enough, the application also crashes after a few photos taken and cancelled. I assume this is because each photo remains in memory until returning to another activity. Combine that with the fact that hitting the cancel button does not produce an activity result in which to handle the previously taken picture, it seems like a limitation of the camera application itself.
My question is: Is there a way of getting around this while still using the built in camera application via intent? Is there a method I can call to keep it from caching the canceled images into memory?
it seems like a limitation of the camera application itself
Please bear in mind that there are hundreds of pre-installed camera apps (across thousands of device models and well over a billion active Android users), and countless more such apps on the Play Store and elsewhere, that might respond to ACTION_CAPTURE_IMAGE. While many have bugs, the bugs vary, and so the behavior that you are seeing is tied to that specific camera app that you happen to be invoking.
I assume this is because each photo remains in memory until returning to another activity
I certainly would not assume this, but if the other app is what is crashing, there is little that you or I can do about it.
Is there a way of getting around this while still using the built in camera application via intent?
You are not in position to fix all the bugs across all the camera apps across all the devices in use.
Is there a method I can call to keep it from caching the canceled images into memory?
There is nothing in the Android SDK for you to tell another app that it has a bug and should stop breaking.
According to Eric Ahn (Android - How to stop camera intent from saving on the phone) the only way around this is to create your own camera activity and handle the callbacks yourself via the camera's API. I'll probably look into it some more later, but I suspect Eric is right.
Related
I'm to the point in my app where I am ready to implement the camera. I've used the intent method before and there is a noticeable delay when launching the phones default camera activity.
I thought I'd take a look at baking the camera into a fragment but looks like it's not exactly a trivial task, especially with Camera and Camera2 and keeping backwards comparability in mind.
Is there a significant performance increase in creating my own camera fragment within my app that would make the effort worth while? I'll be taking a lot of pictures and then uploading them via JCIFS on background threads which means I'll be calling the default camera activity via intent quite a bit.
Is there a significant performance increase in creating my own camera fragment within my app that would make the effort worth while?
Performance? Marginally, at best.
However, ACTION_IMAGE_CAPTURE implementations are notoriously buggy. Relying upon them is unrealistic.
My general recommendation is:
If taking photos is a "nice to have" capability for your app, such that if ACTION_IMAGE_CAPTURE does not work reliably for the user, you and the user are willing to shrug your virtual shoulders and move on, use ACTION_IMAGE_CAPTURE. An example of this would be a note-taking app, where you want to allow users to attach photos.
If taking photos is more important than that, but it is still somewhat of a side feature of your app, try using a library for integrating with the camera, such as mine. Or, give the user the choice between ACTION_IMAGE_CAPTURE and the library's camera capability, so the user can pick between a full-featured camera (that might not work) and something fairly basic from the library (but is more likely to succeed). An example of this would be an app for an insurance claims adjuster, where she needs to be able to document the claim with photos, but the point of the app is bigger than the photos.
If taking photos is the point of your app, integrate with the APIs directly, so you can have complete control over the experience. An example of this would be Snapchat. Or InstantFace, presumably.
I'm using a chooser to allow the user to pick a photo from his gallery or take a new one using his camera (I copied the code from this answer).
Picking an image from the gallery works perfect. The problem is that when I capture an image with the camera It's not returning to the app and just stays in the confirmation screen...
I actually don't even need this screen to be displayed in the first place...
Can I somehow disable it or (if not) just make the Done button work?
Thanks in advance!
Can I somehow disable it
No.
just make the Done button work?
Contact the developers of your camera app, and point out the bug. Perhaps someday they will fix it.
You are using ACTION_IMAGE_CAPTURE. This launches a third-party camera app, to take a picture. There thousands of Android device models. These ship with hundreds of different pre-installed camera apps, and there are many more available for download from the Play Store and elsewhere. Any could be the one that handles a given ACTION_IMAGE_CAPTURE request, and any of them can have bugs.
I am working on a camera implementation similar to what Snapchat offers.
I have created a subclass of SimpleCameraHost to customize the directories and file paths and to handle saveImage(I am cropping the image into a square before I save it to disk). I have also subclassed CameraFragment as you(Mark) have in the demo.
I need to take three pictures(Take pic...user okays it...Move onto second pic..repeat...) before I continue with the flow of the app. I am using the single shot mode. In the Oncreate() of the DemoFragment
SimpleCameraHost.Builder builder =
new SimpleCameraHost.Builder(new MyCameraHost(getActivity(), useFFC));
setHost(builder.useSingleShotMode(true).build());
Question : I need to know how to prevent the cameraview from restarting
the camera every time I pause the app while I'm on the 'okay the pic page'
and resume.Also if I leave the app idle on this page for a while, it seems to freeze and my camera cannot be started again(from any camera app including the default...I have to restart the device). I reckon this happens because I have not released the camera. Could you please direct me as to how I should handle pausing and resuming the app.
I need to know how to prevent the cameraview from restarting the camera every time I pause the app while I'm on the 'okay the pic page' and resume
In the demo app, if I switch to single-shot mode, take a landscape picture using the rear-facing camera, press HOME from the photo-preview screen, return to the app from the recent-tasks list, and press BACK, everything behaves fine, at least on the Nexus 4 that I just tried it on.
Hence, I would suggest that you compare your app to the demo app and see where things differ that might cause this behavior.
If you feel that there is a bug in the library, feel free to file an issue, but you would need to give me a complete set of materials to be able to reproduce the problem. That would include details of the device (e.g., Build.PRODUCT), the code to reproduce it (if it is not one of the demo apps), and the steps I should manually follow to reproduce it.
Also if I leave the app idle on this page for a while, it seems to freeze and my camera cannot be started again(from any camera app including the default...I have to restart the device)
Once again, I cannot reproduce this behavior. Immediately following the steps that I outlined above, I took another picture in single-shot mode, and left the app on the photo-preview screen while I composed the first part of this answer. I just pressed BACK, and everything is normal. So, again:
Compare your app to the demo app, to see if you can determine what you may be doing that might cause this effect
File an issue if you think that it is a bug in the library, but only do so if you can give me steps to reproduce the bug
I want to write an activity that:
Shows the camera preview (viewfinder), and has a "capture" button.
When the "capture" button is pressed, takes a picture and returns it to the calling activity (setResult() & finish()).
Are there any complete examples out there that works on every device? A link to a simple open source application that takes pictures would be the ideal answer.
My research so far:
This is a common scenario, and there are many questions and tutorials on this.
There are two main approaches:
Use the android.provider.MediaStore.ACTION_IMAGE_CAPTURE event. See this question
Use the Camera API directly. See this example or this question (with lots of references).
Approach 1 would have been perfect, but the issue is that the intent is implemented differently on each device. On some devices it works well. However, on some devices you can take a picture but it is never returned to your app. On some devices nothing happens when you launch the intent. Typically it also saves the picture to the SD card, and requires the SD card to be present. The user interaction is also different on every device.
With approach 2 the issues is stability. I tried some examples, but I've managed to stop the camera from working (until a restart) on some devices and completely freeze another device. On another device the capture worked, but the preview stayed black.
I would have used ZXing as an example application (I work with it a lot), but it only uses the preview (viewfinder), and doesn't take any pictures. I also found that on some devices, ZXing did not automatically adjust the white balance when the lighting conditions changed, while the native camera app did it properly (not sure if this can be fixed).
Update:
For a while I used the camera API directly. This gives more control (custom UI, etc), but I would not recommend it to anyone. I would work on 90% of devices, but every now and again a new device would be released, with a different problem.
Some of the problems I've encountered:
Handling autofocus
Handling flash
Supporting devices with a front camera, back camera or both
Each device has a different combination of screen resolution, preview resolutions (doesn't always match the screen resolution) and picture resolutions.
So in general, I'd not recommend going this route at all, unless there is no other way. After two years I dumped by custom code and switched back to the Intent-based approach. Since then I've had much less trouble. The issues I've had with the Intent-based approach in the past was probably just my own incompetence.
If you really need to go this route, I've heard it's much easier if you only support devices with Android 4.0+.
With approach 2 the issues is stability. I tried some examples, but I've managed to stop the camera from working (until a restart) on some devices and completely freeze another device. On another device the capture worked, but the preview stayed black.
Either there is a bug in the examples or there is a compatibility issue with the devices.
The example that CommonsWare gave works well. The example works when using it as-is, but here are the issues I ran into when modifying it for my use case:
Never take a second picture before the first picture has completed, in other words PictureCallback.onPictureTaken() has been called. The CommonsWare example uses the inPreview flag for this purpose.
Make sure that your SurfaceView is full-screen. If you want a smaller preview you might need to change the preview size selection logic, otherwise the preview might not fit into the SurfaceView on some devices. Some devices only support a full-screen preview size, so keeping it full-screen is the simplest solution.
To add more components to the preview screen, FrameLayout works well in my experience. I started by using a LinearLayout to add text above the preview, but that broke rule #2. When using a FrameLayout to add components on top of the preview, you don't have any issues with the preview resolution.
I also posted a minor issue relating to Camera.open() on GitHub.
"the recommended way to access the camera is to open Camera on a separate thread". Otherwise, Camera.open() can take a while and might bog down the UI thread.
"Callbacks will be invoked on the event thread open(int) was called from". That's why to achieve best performance with camera preview callbacks (e.g. to encode them in a low-latency video for live communication), I recommend to open camera in a new HandlerThread, as shown here.
I was wondering whether it is possible to have 2 instances of the camera preview in android. What I mean is running 2 instances of the camera at the same time. If it is, how would one go about this, will there be need to implement an instance on a different thread? I have not used the camera API before, so I would appreciate it if I can have a heads up on the issue, so I don't waste time on it.
Thank you.
It is not possible to have two open connections to the camera - you have to lock the camera in order to get a preview and it can only be locked once. Indeed, if you have the camera locked, and your app crashes before you've unlocked it, then nobody can use the camera!
See http://developer.android.com/reference/android/hardware/Camera.html#open%28int%29
You must call release() when you are
done using the camera, otherwise it
will remain locked and be unavailable
to other applications.
...
RuntimeException: if connection to the
camera service fails (for example, if
the camera is in use by another
process).
That said, you can certainly register a preview callback and take the preview data from your single camera instance to use in multiple views. But be aware of the issues with the YUV format of the raw byte[] data provided by the preview callback: Getting frames from Video Image in Android (note that the preview data is raw from the camera driver and may vary from device to device)
Ignoring the big Why question, your best bet would be to make a service that interacts with the camera, and go from there.