I want to use the Android to take multiple images in one second. The basic idea is to use a Timer at a certain FPS that will trigger the camera to capture images.
The problem is that when I want to trigger the camera more than 1 times in one second, say every 500ms, there will be an error in startPreview. java.lang.RuntimeException: startPreview failed
How can i fixed this?. Thanks.
You should call startPreview() in your onPictureTaken() callback, and nothing guarantees that this callback will be activated at the frame rate you expected. Many cameras provide burst-shot mode, but there is no common API yet. Hopefully, soon this API will arrive.
I take the same error for trying to take many pictures even when the camera is not ready.
So you should define a boolean isItSafeToTakePicture to control if the previous photo-take-action is finished.
Using a boolean like this should solve the issue, even though you may not be able to set 500 ms interval for taking photos, this boolean will define the minimum time limit.
Related
With the languages and libraries I've worked so far, there was always an option to sync the main loop of the program (a game or anything with an always changing context) to the current display's refresh rate. So I had the option to either switch on VSYNC or just let the loop execute as many times per second as it could. I'm referring to SDL2, OpenGL 3.0 with GLFW, the HTML5 canvas etc.
I'm looking for something similar on Android now in OpenGL ES 2.0, but so far all the example code I can find simply uses a variation of sleep and set the framerate to 60 or 30. So they basically count the amount of time passed since the last iteration, and only advance further and call the requestRender() function if a given amount of time has passed (0.016 ms in case of 60 frames per second etc.).
I'm simply wondering if there's a better option than this or not. I'm just concerned that not every phone has the same screen refresh rate, so hard coding any amount doesn't seem to be a desired method. As far as I understand it is not that simple to figure out the given phone's refresh rate, or at least it is not possible with "pure" Java and OpenGL.
What you need to do is match the display's frame rate, and advance game state according to how much time has elapsed since the previous frame. There are two ways to go about this:
Stuff the BufferQueue full and rely on the "swap buffers" back-pressure.
This is very easy to implement: just swap buffers as fast as you can. In early versions of Android this could actually result in a penalty where SurfaceView#lockCanvas() would put you to sleep for 100ms. Now it's paced by the BufferQueue, and the BufferQueue is emptied as quickly as SurfaceFlinger is able.
Use Choreographer.
Choreographer allows you to set a callback that fires on the next VSYNC. The actual VSYNC time is passed in as an argument. So even if your app doesn't wake up right away, you still have an accurate picture of when the display refresh period began. Using this value, rather than the current time, yields a consistent time source for your game state update logic.
source: https://source.android.com/devices/graphics/arch-gameloops
For an Android App, that will show the value of an internal sensor (e.g. Acceleration) in a graph, i need to find a way to access this signal periodically.
At the moment i am using a SensorEventListener, but unfortunately this only gives me the possibility to get a value whenever it changes.
Since I want to display the graph (point to point) in dependency of the time, this means it would directly draw a line from the old to the new value (and if the old value has been a long time, it looks like a linear changing of the value).
So my question: How can I get access to a sensor's data periodically?
The documentation for SensorManager says that registerListener(android.hardware.SensorEventListener, android.hardware.Sensor int)
"Registers a SensorEventListener for the given sensor at the given sampling frequency."
To get these events, though, your application would need to be active (hold a partial wake lock). It would be better to do this in a background service so that the application doesn't need to remain active. See for example, SensorEventListener in a service
So in the end i used a timer, which checked the values from my sensor, which I put into an array, periodically.
Unfortunately registerListener didnt work, since the value is just a suggestion for the system.
Thanks though for the help.
My app is basically is a schedule app, where I'd like to show notifications x minutes before an (user-set) event occurs.
I read the documentation, but it only covers showing a notification at the time the notification code is being executed (which I guess is the only way).
My guess is that if I want to have notifications show up even when my app is closed, I need to somehow make the app run in the background and constantly check for upcoming events, calculate the time left, and show a notification when the time left equals the time before the event the user chose to be notified at.
I read this question (+answers): How to get android notifications when app was closed?.
There is a pretty detailed answer (using services) I could simply implement, but the other answer claims this approach is "crappy".
The second answer also suggest the usage of AlarmManager which, after reading the doc, doesn't sound that bad (executing code at a specific time).
However, since I'm targeting API19 it's "inexact" (according to the doc).
So what exactly is the most efficient (and the right) way to do this?
You need to implement alarm manager with service. Set the time user chose and show notification at that time. The sample shows a Toast, you can use notification/sound/dialog, anything.
Check out this sample.
I want to synchronize other sensor data with the video I'm recording, and so I'd like to record "how far am I into the video" when the sensor is triggered. Is there any way to do this? I couldn't find an appropriate method on the MediaRecorder class.
Another solution would be to just get the precise start time of the video recording, but my tests show that the video starts ~1sec after calling mediarecorder.start, but it's not consistent.
You have raised an interesting topic.
If you refer to the documentation in the developer page, the following diagram states the recording is supposed to start when the start() method is called.
Your solution is supposed to be correct albeit there is a lag up to 1 sec. I would do it the same way
I went through the MediaRecorder class methods, the only method that seems to be useful is the callback setOnInfoListener().
Set it and see if you will get some kind of information when the recording starts! I haven't tried it yet though.
I have worked on a simple application. It application includes diffrent levels that can be solved by placing some components inside a canvas, dragging them to the right place and so on.
The application is working fine, but when trying it on my HTC Desire 2.2, I sometimes get the warning message:
Sorry:
Activity xxxxx is not respoding.
Force Close - Wait
If I press the wait-button and let it be for some seconds (up to ~30 sec sometimes), then it runs without any problems. I donĀ“t know where I should start debugging the code, since it happenes only once in a while.
I have read the stuff in google developer site and it was just mostly very general stuff that did not really help.
any ideas?
since, I was not able to debug the problem myself, I am going to post the most important parts of the application. Please check and let me know If I need to post more classes.
//Evrything else
Bitmap bitmap;
GraphicObject.Coordinates coords;
for (GraphicObject graphic : _graphics) {
bitmap = graphic.getGraphic();
coords = graphic.getCoordinates();
canvas.drawBitmap(bitmap, coords.getX(), coords.getY(), null);
}
// draw current graphic at last...
if (_currentGraphic != null) {
bitmap = _currentGraphic.getGraphic();
coords = _currentGraphic.getCoordinates();
canvas.drawBitmap(bitmap, coords.getX(), coords.getY(), null);
}
Android has a relatively good profiler support built in.
When you know the place where this ADNR will show up (e.g. with in one method of your activity, you can put that block in a tracing block:
Debug.startMethodTracing("xyz");
<your code goes here>
Debug.stopMethodTracing()
This will upon activation write a trace file to /sdcard/xyz.trace
You can later (after such a ADNR occurred) obtain it via
adb pull /sdcard/xyz.trace
and analyze it via
traceview xyz.trace
Within the traceview screen, you see the method with its called methods and you can then see the timings.
See http://developer.android.com/guide/developing/tools/adb.html and http://developer.android.com/guide/developing/tools/traceview.html
Are you doing network connections on the main thread? Or Time.sleep()'s. Or extremely long running calculations?
Something in your app's main thread is taking more than 5 (or is it 10?) seconds to complete.
I think you are creating the 30 second sleep on the main thread, if so, the application will be unresponsive for about 30 seconds and the android system will show force close dialog will show up after 5 second. Try creating the 30 second pause and action on a new thread. Check android developers site for more information about threads.
And if you don't know where to start debugging, check your logcat log and search for errors or warnings. Check this -> http://www.droidnova.com/debugging-in-android-using-eclipse,541.html for some information about logcat.
Hope that helped. :) Good luck.
Edit: Then i think that you should put the functions that the wait button performs inside a new thread, so that the application becomes responsive instantly and the child thread remains unresponsive, which doesnt matter.
Edit Again: oh, i get it now, sorry for the misunderstanding, so you are not sure where the problem is, try searching for any network connections, sleep/pauses in your code. Oh, and connect your phone to your computer, run the app by pressing F5 and try to search for warnings or errors in logcat just when the force close box opens. And try to copy the logcat log and send it to me, and ill check whats wrong.
You can use the new StrictMode to detect what is causing your UI thread to hang.
Take a look at this link.
It is only available for GingerBread (API level 9), so you can just test it on the emulator, perform the necessary cleanup, and then remove the StrictMode code