Closed fmanoir closed 10 months ago
D’après les logs, il semblerait que le callback onConfigured()
de la CaptureSession est appelée en parallèle de (ou après) un appel a closeCamera()
et fait donc appel a une classe qui n'est plus instanciée.
Y a-t-il un scenario ou une suite d’opérations typique qui permette de reproduire régulièrement ce crash ?
Oui, pour le scenario, je pense
Activity A (ScannerCompatActivity) -> Activity B -> Activity A (ScannerCompatActivity) juste pour valider un traitement puis ->Activity C
peut être super.onResume(); lance onConfigured et super.onPause(); lance closeCamera()
J'essai même de mettre un try/catch dans notre onPause pour skipper l'exception mais ça fonctionne plus
D’après les logs il semble que le passage sur la ScannerCompatActivity soit très rapide au point que l'appel a onPause()
se produit avant la fin de l'initialisation de la camera qui suit le onResume()
et continue en parallèle:
2024-01-10 15:14:21.985 21832-23918 BARCODE com.geodis.mobiprep D Configuration request sent ==> `startPreview()`
2024-01-10 15:14:21.985 21832-23918 BARCODE com.geodis.mobiprep D Preview analysis loop start method done ==> `startPreview()`
2024-01-10 15:14:21.986 21832-21832 BARCODE com.geodis.mobiprep D Starting camera release 177157145 ==> `closeCamera()`
2024-01-10 15:14:21.986 21832-23918 BARCODE com.geodis.mobiprep I Capture session is now configured and will start the capture request loop 177157145 ==> `onConfigured()`
2024-01-10 15:14:21.986 21832-21832 BARCODE com.geodis.mobiprep D * Closing camera capture session ==> `closeCamera()`
2024-01-10 15:14:21.987 21832-21832 BARCODE com.geodis.mobiprep D * Clearing camera capture builder ==> `closeCamera()`
2024-01-10 15:14:21.987 21832-23918 BARCODE com.geodis.mobiprep D Using metering zone (72,542) (648,664) ==> `onConfigured()`
2024-01-10 15:14:21.987 21832-21832 BARCODE com.geodis.mobiprep D * Camera device closing ==> `closeCamera()`
2024-01-10 15:14:21.988 21832-23918 BARCODE com.geodis.mobiprep D Setting AF mode to 4 ==> `onConfigured()`
Les deux derniers logs de la fonction onConfigured()
effectuent le meme appel de fonction sur la meme variable, mais seul le deuxième cause l'erreur car la variable est mise a null entre temps, donc closeCamera()
se déroule bien en parallèle de onConfigured()
.
La seule solution de notre coté serait d'englober onConfigured()
dans un grand try/catch. Alternativement, serait-il possible de ralentir de quelques millisecondes le changement d’activité afin d'attendre la fin de son initialisation ?
Ok, j'essaie de faire ça, mais, ceci n'est pas lié aussi au souci de #150 ; le onConfigured() mal fonctionne dans deux appel consécutive
Re,
Possible de publier une MAJ avec l'englober onConfigured() dans un grand try/catch ?
C'est possible, je m'occupe de ca demain apres-midi
Le fix est disponible dans la version 2.4.2, qui sera disponible sur maven central sous peu.
Merci fonctionne parfaitement
Bonjour,
Bonjour @DaSpood, @marcanpilami ,
Lorsque nous exécutons par fois un scan en utilisant la librairie au sein de notre application, notamment sur les appareils Xcover 4S et 5, nous rencontrons un problème d'instabilité qui conduit à un crash de l'application. Voici les traces que j'ai pu récupérer suite à l'arrêt inattendu de l'application :
Emplacement de Plantage
le crache se produit dans super.onpause()
Log