Comment une coque peut détruire votre portable ?!

Aujourd’hui, je vais vous parler d’une histoire assez cocasse qui m’est arrivée récemment : du jour au lendemain, sans aucune explication, mon téléphone s’est mis à crasher de manière totalement aléatoire. En une journée, il s’est arrêté de lui-même une dizaine de fois sans que je saisisse la raison au premier abord. Pourtant la coupable n’était ni une application, ni un module enfoui dans la mémoire, elle était directement dans ma main : la coque. Et là je sais ce que vous vous dites, mais non, ici ce n’est pas l’histoire d’une énième coque trop épaisse qui fait surchauffer le processeur, non non, c’est bien plus édifiant que cela.

Ma première intuition fut celle d’une application instable qui cause cette panique système en positionnant l’OS dans un état inattendu. Le problème, c’est que le premier crash a eu lieu en ouvrant Brave, le second en ouvrant Instagram, etc…

En fait, je ne pouvais incriminer aucune d’entre elles car le crash intervenait au lancement d’applications diverses et variées. Mais en réalité je passais complètement à côté de l’essentiel : ce qu’il fallait voir, c’est que ces erreurs intervenaient à chaque fois au moment où j’ouvrais ma coque, que je déverrouillais mon téléphone et que je lançais une application, c’était là l’unique point commun.

Après avoir passé une pénible journée avec un téléphone instable qui s’éteint presque systématiquement, il était indispensable que j’investigue cette affaire. Mon téléphone étant sous Android non-rooté, la solution la plus adaptée pour du débogage (que j’ai déjà éprouvé par le passé) est sans hésitation Android Debug Bridge.

La première étape a consisté à connaître l’erreur qui déclenche l’arrêt du téléphone ; en d’autres termes, on fait une autopsie de l’état du téléphone avant de pouvoir désigner un coupable :

adb shell dumpsys dropbox --print SYSTEM_BOOT

======================================== 2025-09-16 12:33:16 SYSTEM_BOOT (text, 520 bytes) 
isPrevious: true 
Build: samsung/p3sxeea/p3s:15/AP3A.240905.015.A2/G998BXXSGHYH1:user/release-keys 
Hardware: exynos2100 
Revision: 22 
Bootloader: G998BXXSGHYH1 
Radio: null 
Kernel: Linux version 5.4.242-30958140-abG998BXXSGHYH1 (dpi@21DND905)

Ci-dessus, ce sont les informations qui ont été sauvegardées au moment du reboot lors du plantage, elles ne permettent pas vraiment de conclure quoi que ce soit sur l’événement mais on s’assure à minima que ce dernier a bien été remarqué par le système, et qu’il y a donc de fortes chances pour qu’on trouve des traces (logs) dans les fichiers.

La seconde étape consiste à vérifier l’intégrité des partitions du disque, en effet, des rapports sont sauvegardés lors de la vérification automatique au démarrage, après le plantage :

adb shell dumpsys dropbox --print SYSTEM_FSCK

[...]

Info: superblock features = 3499 : encrypt extra_attr project_quota quota verity casefold compression 
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000 
Info: Segments per section = 1 
Info: Sections per zone = 1 
Info: total FS sectors = 58933243 (230207 MB) 
Info: CKPT version = 6f120c 
Info: version timestamp cur: 48155878, prev: 46546500 
Info: SPO 2/23 
Info: checkpoint state = 56 : crc fsck compacted_summary orphan_inodes sudden-power-off 
[FSCK] Check node 47392 / 473929 (10.00%) 
[FSCK] Check node 94784 / 473929 (20.00%) 
[FSCK] Check node 142176 / 473929 (30.00%) 
[FSCK] Check node 189568 / 473929 (40.00%) 
[FSCK] Check node 236960 / 473929 (50.00%) 
[FSCK] Check node 284352 / 473929 (60.00%) 
[FSCK] Check node 331744 / 473929 (70.00%) 
[FSCK] Check node 379136 / 473929 (80.00%) 
[FSCK] Check node 426528 / 473929 (90.00%) 
[FSCK] Check node 473920 / 473929 (100.00%)

[...]

Ici ce qu’il faut voir, c’est l’inscription sudden-power-off qui confirme bien qu’il y a eu un arrêt impromptu qui ne correspond pas à un arrêt docile avec le bouton.

Mais il y a plus grave…

Pass 1: Checking inodes, blocks, and sizes 
Pass 2: Checking directory structure 
Pass 3: Checking directory connectivity 
Pass 4: Checking reference counts 
Pass 5: Checking group summary information 

Total Free blocks count wrong (140486, counted=140645). 
Fix? yes 

Total Free inodes count wrong (38335, counted=38347). 
Fix? yes 

cache: ***** FILE SYSTEM WAS MODIFIED *****

Le plantage abrupt a créé des incohérences sur certaines partitions comme ici sur celle de /cache. Ce qui explique pourquoi j’ai constaté que mon téléphone avait de grandes difficultés à redémarrer : le système est corrompu au niveau de certains fichiers temporaires qui devaient sans doute être manipulés au moment où le système d’exploitation s’est stoppé.

Heureusement, Android dispose d’un utilitaire permettant de réparer ces incohérences. Le portable finit donc toujours par redémarrer.

Jusqu’à maintenant, nous sommes restés assez distants du cœur du problème ; nous avons tout au plus confirmé le bug, mais impossible de donner plus de détails. Il est donc temps de s’enfoncer un peu plus profondément pour comprendre l’essence même de ce souci.

En prenant de la hauteur, on s’intéresse aux crashs d’ordre général, et en réalité ils sont bien plus parlants que les étapes précédentes (enfin, ils nous indiquent la solution très franchement).

En effectuant la commande suivante :

adb shell dumpsys dropbox --print

On voit s’afficher les informations suivantes :

2025-09-16 12:33:00 clockpackage (text, 73 bytes) 
2025-09-16 12:33:02 clockpackage (text, 55 bytes) 
2025-09-16 12:33:16 SYSTEM_BOOT (text, 520 bytes) 
2025-09-16 12:33:16 SYSTEM_LAST_KMSG_0_20250916_123316_TP (compressed text, 15863 bytes) 
[0: 0.534547 ] RTC TIME: 2025-09-16 10:15:48(0x04)AM 
2025-09-16 12:33:16 SYSTEM_AUDIT (text, 520 bytes) 
2025-09-16 12:33:16 SYSTEM_FSCK (text, 7892 bytes) 
2025-09-16 12:33:18 clockpackage (text, 34 bytes)
2025-09-16 12:33:18 clockpackage (text, 102 bytes) 
2025-09-16 12:33:18 clockpackage (text, 121 bytes) 
2025-09-16 12:33:20 clockpackage (text, 47 bytes) 
2025-09-16 12:33:23 com.samsung.android.app.reminder (text, 54 bytes)

BINGO ! Ici la ligne SYSTEM_LAST_KMSG_0_20250916_123316_TP nous indique clairement que le système a enregistré un joli petit rapport du dernier KMSG (crash profond du kernel 😰) intervenu le 16 septembre 2025 à 12h33 et 16 secondes.

Bon, ce n’est pas un petit malaise passager, c’est assez grave : on se rend donc directement à l’intérieur de ce rapport EXTRÊMEMENT complet, et on constate plusieurs choses :

• RESET CAUSE - THERMAL RESET
• TMU TRIP & PSHOLD low Detected (le contrôleur thermique a déclenché une coupure d’alimentation)
• set_reset_reason: ... TP(10) (TP = Thermal Protect)
• Kernel last temperature ... TZ_LIT/GPU/NPU/CP: 125 (dernières températures enregistrées très élevées)

Pour être synthétique : le processeur a eu très chaud, il s’est emballé en quelques secondes. Ce qui a causé l’arrêt prématuré.

Mais bon, je vous rassure en Bretagne, surtout en septembre, il est difficile de faire surchauffer un téléphone avec l’air extérieur. De même, je peux d’ores et déjà écarter le fait que ce soit ma coque qui fasse surchauffer le processeur car cela fait maintenant presque 4 ans qu’elle est utilisée, sans avoir causé le moindre petit pic de température.

Non, ici l’explication repose plus sur une exécution bloquante qui surcharge l’appareil, jusqu’à la surchauffe.

Avant de conclure cette histoire, je dois vous spécifier un point important : ma coque. Ce n’est pas n’importe quelle coque, il s’agit d’une coque officielle Samsung avec une matrice LED intégrée à la face avant, en voici un aperçu :

Bon, c’est un peu gadget mais c’est très pratique pour afficher l’heure et effectuer quelques actions simples sans ouvrir le rabat de la coque (décrocher, arrêter le réveil, etc…).

Mais c’est plutôt le principe de fonctionnement qui nous intéresse ici : comment diable peut-on faire ce genre de chose avec une simple coque ? Eh bien, en réalité, il y a une puce NFC à l’arrière de la coque qui permet la communication entre le téléphone et la matrice LED.

Mais voilà, je vous dis cela avec un peu d’amertume car il se trouve que cette fameuse matrice LED ne fonctionne plus depuis environ un an sur ma coque ; cependant, la coque reste pleinement fonctionnelle dans son rôle de coque classique, donc je la garde même sans cette fonctionnalité LED.

Maintenant, revenons une dernière fois au débogage Android. Il reste un dernier endroit à regarder : le dossier des pierres tombales d’Android (oui, cela s’appelle vraiment comme ça…). En farfouillant dans ce dossier sinistre, je finis par tomber sur la pierre tombale correspondant à l’un de mes crashs de la journée ; ce fichier contient tout ce qui s’est passé en clair, juste avant l’erreur fatale.

Je constate que c’est le processus com.android.nfc qui plante ~7 secondes après son lancement, et j’ai ENCORE MIEUX : la fonction exacte qui cause le plantage est écrite noir sur blanc : GKI_init() → NfcAdaptation::Initialize() → chemin « coverAttached », qui est tout simplement la fonction appelée pour détecter si la coque LED est bien attachée au téléphone.

Et c’est ainsi que l’affaire est complètement élucidée ! Bon, cela n’explique pas pourquoi mon téléphone ne supporte plus ma coque (au sens propre comme figuré) du jour au lendemain. Il s’agit sans doute d’une fin de prise en charge, ou alors d’une mise à jour du module NFC qui n’a pas pris cette vieille éventualité en considération, car oui, ce type de coque n’a été vendu par Samsung que pendant une seule année, preuve que ce n’était pas un produit miracle. Il ne me reste plus qu’à trouver une nouvelle coque…