Après déplacement des homes, QEMU ne retrouvait plus ses keymaps et le lanceur annonçait un démarrage réussi malgré des échecs. Les outils retrouvent leurs chemins locaux et contrôlent désormais le démarrage de QEMU et du relais réseau, y compris un port agent occupé.
Après installation d’une application et redémarrage conservant la NAND, SpringBoard restait verrouillé. L’agent v11 expose screen et wake ; le client réveille l’écran par SBDimScreen, effectue le glissement normal et vérifie le déverrouillage. start -W et wait terminent avec succès après cette vérification. Le client refuse les gestes avant disponibilité du tactile et le déverrouillage automatique si un code est actif. SBApplicationRequestedDeviceUnlock n’est pas utilisé : sur ce firmware il affiche un clavier de code même sans code activé.
Validation : compilation armv6 avec SDK 2.2.1 et entitlements ; boot sans débogueur en 36 s ; push-app HelloEmu, redémarrage sans reconstruction ni réinitialisation de NAND en 47 s, locked=0, lancement réussi, application au premier plan et log HelloEmu: launched. Vérifications du client déjà déverrouillé, code actif et ancien agent. Syntaxe Bash/Python, compilation du relais avec -Wall, erreur QEMU volontaire et conflit sur le port 7788 vérifiés.
L’image 5H11a-agent-v11 est construite séparément dans l’environnement local. Les images et la NAND d’origine sont préservées. La base v10 doit recevoir l’agent v11 pour ce workflow. Home/Power peuvent encore déclencher un défaut lors de la reprise de l’écran ; aucun correctif matériel n’est revendiqué.
Dépendances et wrappers restaurés localement seulement. Aucun changement Compose, merge, publication d’image Docker ni déploiement.
Après déplacement des homes, QEMU ne retrouvait plus ses keymaps et le lanceur annonçait un démarrage réussi malgré des échecs. Les outils retrouvent leurs chemins locaux et contrôlent désormais le démarrage de QEMU et du relais réseau, y compris un port agent occupé.
Après installation d’une application et redémarrage conservant la NAND, SpringBoard restait verrouillé. L’agent v11 expose screen et wake ; le client réveille l’écran par SBDimScreen, effectue le glissement normal et vérifie le déverrouillage. start -W et wait terminent avec succès après cette vérification. Le client refuse les gestes avant disponibilité du tactile et le déverrouillage automatique si un code est actif. SBApplicationRequestedDeviceUnlock n’est pas utilisé : sur ce firmware il affiche un clavier de code même sans code activé.
Validation : compilation armv6 avec SDK 2.2.1 et entitlements ; boot sans débogueur en 36 s ; push-app HelloEmu, redémarrage sans reconstruction ni réinitialisation de NAND en 47 s, locked=0, lancement réussi, application au premier plan et log HelloEmu: launched. Vérifications du client déjà déverrouillé, code actif et ancien agent. Syntaxe Bash/Python, compilation du relais avec -Wall, erreur QEMU volontaire et conflit sur le port 7788 vérifiés.
L’image 5H11a-agent-v11 est construite séparément dans l’environnement local. Les images et la NAND d’origine sont préservées. La base v10 doit recevoir l’agent v11 pour ce workflow. Home/Power peuvent encore déclencher un défaut lors de la reprise de l’écran ; aucun correctif matériel n’est revendiqué.
Dépendances et wrappers restaurés localement seulement. Aucun changement Compose, merge, publication d’image Docker ni déploiement.
Mahtan
changed title from Fiabiliser la reprise du simulateur iPhone OS 2 to Fiabiliser le simulateur et déverrouiller SpringBoard après installation2026-09-30 17:09:03 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Après déplacement des homes, QEMU ne retrouvait plus ses keymaps et le lanceur annonçait un démarrage réussi malgré des échecs. Les outils retrouvent leurs chemins locaux et contrôlent désormais le démarrage de QEMU et du relais réseau, y compris un port agent occupé.
Après installation d’une application et redémarrage conservant la NAND, SpringBoard restait verrouillé. L’agent v11 expose screen et wake ; le client réveille l’écran par SBDimScreen, effectue le glissement normal et vérifie le déverrouillage. start -W et wait terminent avec succès après cette vérification. Le client refuse les gestes avant disponibilité du tactile et le déverrouillage automatique si un code est actif. SBApplicationRequestedDeviceUnlock n’est pas utilisé : sur ce firmware il affiche un clavier de code même sans code activé.
Validation : compilation armv6 avec SDK 2.2.1 et entitlements ; boot sans débogueur en 36 s ; push-app HelloEmu, redémarrage sans reconstruction ni réinitialisation de NAND en 47 s, locked=0, lancement réussi, application au premier plan et log HelloEmu: launched. Vérifications du client déjà déverrouillé, code actif et ancien agent. Syntaxe Bash/Python, compilation du relais avec -Wall, erreur QEMU volontaire et conflit sur le port 7788 vérifiés.
L’image 5H11a-agent-v11 est construite séparément dans l’environnement local. Les images et la NAND d’origine sont préservées. La base v10 doit recevoir l’agent v11 pour ce workflow. Home/Power peuvent encore déclencher un défaut lors de la reprise de l’écran ; aucun correctif matériel n’est revendiqué.
Dépendances et wrappers restaurés localement seulement. Aucun changement Compose, merge, publication d’image Docker ni déploiement.
Fiabiliser la reprise du simulateur iPhone OS 2to Fiabiliser le simulateur et déverrouiller SpringBoard après installation