Exploitation et développement

Service de premier plan

Le service démarre après l’amorçage par défaut et maintient canal de contrôle, voix, caméra et médias. Des verrous Wi-Fi et CPU protègent les sessions actives ; après la mort du processus, le service rouvre le tableau de bord. L’état désiré converge après redémarrage du réseau, de l’application, de HA ou de l’intégration ; les actions hors ligne sont jetées. La sauvegarde Android est désactivée. Un identifiant révoqué ramène à l’association.

Dépannage

Vérifiez d’abord en ligne/dernière vue, état du service et révision face à l’accusé. Des coupures répétées après environ 45 secondes indiquent des pulsations absentes ou une ancienne application/intégration ; vérifiez donc d’abord les versions. Pour TLS, comparez URL, DNS, expiration et empreinte, puis testez l’adresse HA locale directe. Vérifiez la voix par permission micro, pipeline, STT/TTS, VAD et volume multimédia ; les caméras par orientation, permission et accès séquentiel. Un HTTP 400 de fournisseur impose de vérifier type, liaison et accès HA. En cas d’erreur de configuration, l’application conserve la dernière révision valide. Les diagnostics HA masquent identifiants et secrets.

Construction et tests

L’application reste en Java avec minSdk 17 et compileSdk 36. La CI de push sur le runner Android /opt/android-sdk lance tests Java, lint, construction debug et contrôle de l’artefact API 17. La CI documentaire valide pages, titres, liens et champs JSON, puis construit DE/EN/FR avec Zensical --clean --strict. Géométrie d’aperçu, vecteurs de protocole et injection de pannes font partie de la recette.

Versions

Application et intégration commencent à 0.1.0 ; 1.0.0 est le premier protocole conjointement stable. Les tags fixent versionName et les artefacts reproductibles. Forgejo fait autorité et publie APK/F-Droid et documentation. Association, reconnexion, Assist, caméra, lecteur, capteurs, parité du tableau et trois langues doivent réussir avant publication.