¿Cómo resolver el error ANR al invocar la cámara?

Tengo dos botones en el menú principal. Invoco la cámara cuando presiono el primer botón. Aquí no tuve ningún problema. La cámara funciona correctamente. Después de tomar la foto, vuelvo al menú principal y otra vez presiono el botón 1. Aquí obtuve el problema. Cámara que invoca correctamente. Pero tengo un ANR error (Reason: keyDispatchingTimedOut) mientras estoy tomando la foto. Cómo resolver este problema?

Editar::

Estoy usando código siguiente,

Escuchador de botones ,

 Button imageButton = (Button) findViewById(R.id.button1); imageButton.setOnClickListener(new View.OnClickListener() { public void onClick(View arg0) { Intent intent = new Intent(); intent.setClass(activity, ImageActivity.class); startActivity(intent); } });

ImageActivity.java

 public class ImageActivity extends Activity implements SurfaceHolder.Callback { private Camera camera = null; private SurfaceHolder surfaceHolder = null; private boolean previewRunning = false; private Button btnDone, btnCapture, btnRetake; private Bitmap mBitmap; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); getWindow().setFormat(PixelFormat.TRANSLUCENT); requestWindowFeature(Window.FEATURE_NO_TITLE); getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); setContentView(R.layout.surface_screen); SurfaceView surfaceView = (SurfaceView) findViewById(R.id.camerapreview); surfaceHolder = surfaceView.getHolder(); surfaceHolder.addCallback(this); surfaceHolder.setType(SurfaceHolder.SURFACE_TYPE_PUSH_BUFFERS); surfaceHolder.setFixedSize(getWindow().getWindowManager() .getDefaultDisplay().getWidth(), getWindow().getWindowManager() .getDefaultDisplay().getHeight()); LayoutInflater controlInflater = LayoutInflater.from(getBaseContext()); final View viewControl = controlInflater.inflate(R.layout.control, null); LayoutParams layoutParamsControl = new LayoutParams( LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT); activity.addContentView(viewControl, layoutParamsControl); btnCapture = (Button) findViewById(R.id.takepicture); btnDone = (Button) findViewById(R.id.send); btnCapture.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { camera.takePicture(null, picCalBac, picCalBac); } }); Camera.PictureCallback picCalBac = new PictureCallback() { public void onPictureTaken(byte[] data, Camera camera) { if (data != null) { mBitmap = BitmapFactory.decodeByteArray(data, 0, data.length); } } }; public void surfaceChanged(SurfaceHolder holder, int format, int w, int h) { if (previewRunning) { camera.stopPreview(); } try { camera.setPreviewDisplay(surfaceHolder); } catch (IOException e) { Log.d("IOException", e.getMessage()); } camera.startPreview(); previewRunning = true; } public void surfaceCreated(SurfaceHolder arg0) { camera = Camera.open(0); } public void surfaceDestroyed(SurfaceHolder arg0) { camera.stopPreview(); previewRunning = false; camera.release(); } }

Es posible que haya pasado por este enlace durante la búsqueda del error.

Aunque nunca tuve tal problema, después de leer en Internet, esto es lo que entiendo:

Descripción:

ANR o aplicación no responde error se produce cuando un proceso en el subproceso principal toma demasiado tiempo (algo como> 5 segundos). Android mata ese proceso y cualquier otro relacionado por diseño para ahorrar los recursos del dispositivo.

La solución es ejecutar tareas caras de recursos en otro hilo y, a continuación, publicar o actualizar el hilo principal en consecuencia.

Ver esto: Android ANR keyDispatchingTimedOut

Así que en su caso puede estar en conflicto dos hilos diferentes de la que se mantiene funcionando durante mucho tiempo y Android los mata. El siguiente código relacionado también se ve afectado.

Así que mejor clasificar su código, escriba cada nueva tarea en diferentes Thread,Handler y si está haciendo una tarea de interfaz de usuario, utilice runOnUIThread . Async Task también es muy práctico.

Otra cosa es tratar de eliminar la dependencia del código en otro. Escriba algunos valores predeterminados ya partir de eso puede enviar al usuario de nuevo a la primera tarea si no se hace correctamente.

Creo que el error es de su estilo de codificación, no debido a cualquier error específico en su código.

Es necesario mejorar su código particular para que funcione de manera eficiente y para que vea estos 2 enlaces:

Diseño para la receptividad
Roscado sin dolor

EDITAR:

Esto lo leí en alguna parte y encontré eficaz es,

¿Cómo investigar ANR?

Primero, revise su código y busque puntos vunerables y operaciones largas. Los ejemplos pueden incluir el uso de sockets, bloqueos, durmientes de hilos y otras operaciones de bloqueo dentro del subproceso de sucesos. Debe asegurarse de que todo esto suceda en hilos separados. Si nada parece ser el problema, utilice DDMS y active la vista de subprocesos. Esto muestra todos los subprocesos en su aplicación similar a la traza que tiene. Reproduzca el ANR y actualice el subproceso principal al mismo tiempo. Eso debe mostrarle exactamente lo que está pasando en el momento de la ANR

También Si ANR es causado debido a hilos?

puede utilizar el servicio para eso, por lo que su aplicación puede realizar las tareas que consumen mucho tiempo dentro de service.onStart (), pasando datos (por ejemplo) en la intención utilizada para iniciar el servicio.

Sin embargo, los servicios se ejecutan en el hilo principal de la aplicación. Si se necesita un hilo separado, puede ser creado por el servicio dentro de onStart ().

Ya hay una clase incorporada que hace esto: IntentService

También se encontró una útil aplicación de biblioteca SalomonBrys / ANR-WatchDog

Android applications normally run entirely on a single (ie main) thread . Esto significa que todo lo que su aplicación está haciendo en el hilo principal que lleva long time para completar puede desencadenar el ANR dialog porque su aplicación no se da la oportunidad de manejar el input event o I ntent broadcast . En ese caso, puede utilizar StrictMode para ayudar a encontrar operaciones de ejecución potencialmente largas, como operaciones de red o de base de datos, que podría estar realizando accidentalmente su subproceso principal. Si encuentras violaciones que te parezcan problemáticas, hay una variedad de herramientas para ayudarlas a resolverlas: threads , Handler , AsyncTask , IntentService , IntentService recuerda que vino de API Level 9

Código de ejemplo para activar desde el principio en su método de onCreate() Application , Activity u otro componente de aplicación:

  StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() // or .detectAll() for all detectable problems .penaltyLog() .build()); StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects() .detectLeakedClosableObjects() .penaltyLog() .penaltyDeath() .build());

Creo que ya sabes sobre esto,

El modelo de hilo único puede producir un rendimiento bajo en las aplicaciones de Android que no consideran las implicaciones. Dado que todo sucede en un solo hilo que realiza operaciones largas, como acceso a la red o consultas de base de datos, en este hilo bloqueará toda la interfaz de usuario. No se puede enviar ningún evento , incluidos los eventos de dibujo, mientras la operación larga está en curso. * Desde la perspectiva del usuario, la aplicación aparece colgada * . Aún peor, si el hilo de la interfaz de usuario está bloqueado durante más de unos segundos (aproximadamente 5 segundos en la actualidad), se le presenta al usuario el infame "aplicación no responde" (ANR).

Una ANR ocurre cuando una operación larga tiene lugar en el hilo "principal". Este es el subproceso del bucle de eventos y, si está ocupado, Android no puede procesar ningún otro evento GUI en la aplicación y, por lo tanto, abre un diálogo ANR.

¿Qué desencadena la ANR?

En Android, la capacidad de respuesta de las aplicaciones es supervisada por los servicios del sistema de Administrador de Actividades y de Administrador de Ventanas. Android mostrará el diálogo ANR para una aplicación en particular cuando detecte una de las siguientes condiciones:

 * No response to an input event (eg key press, screen touch) within 5 seconds * A BroadcastReceiver hasn't finished executing within 10 seconds

Cómo resolverlo, por favor, mire Diseño para la capacidad de respuesta

EDITAR:

Por lo tanto, intente utilizar otro hilo de trabajo, manejador, AsyncTask o UIThread para su material de cámara (grabador de medios) en lugar de hilo principal de actividad.

1). Haz "adb shell cat /data/anr/traces.txt" para ver qué estaba haciendo tu aplicación en ese momento. Este es el primer paso que debe tomar: entienda qué está haciendo su aplicación que está causando la ANR.

Cuando la ANR sucede todas las pilas del proceso se escriben en este archivo, con el proceso que se acusa de la ANR primero. Todo esto lo que está haciendo es descargar el archivo para que pueda verlo. Así que sólo quiere verlo algún tiempo después de la ANR, antes de que ocurra otra ANR.

2). Si nada parece ser el problema, utilice DDMS y active la vista de subprocesos. Esto muestra todos los subprocesos en su aplicación similar a la traza que tiene. Reproduzca el ANR y actualice el subproceso principal al mismo tiempo. Eso debería mostrarle exactamente lo que está pasando en el momento de la ANR.

Fore more solo pasar por esto http://android-developers.blogspot.com/2009/05/painless-threading.html

Puede ser que inicializar y poner en marcha la grabadora de medios en el hilo principal propio ya sea en Oncreate() o en Onresume() , en lugar de lanzar la cámara en el uso de hilo principal separeate Handler para lanzar una cámara para tomar fotos, actuará como hijo de la interfaz principal hilo

Utilizando el Handler reducirá el tiempo y la ANR no se producirá.

Parece que el recurso de la cámara no está siendo liberado, lo que provoca la ANR .

El código parece un poco desordenado. Puedes echar un vistazo al ejemplo de api para la vista previa de la cámara :

Tendrá que implementar onPause y onResume para que funcione confiablemente.