1 votes

ADB dumpsys batterystats - Comment le lire?

Pourquoi diable la commande adb shell dumpsys batterystats n'imprime-t-elle pas des horodatages réguliers? (Comme le fait usagestats par exemple, ou littéralement tout ce qui existe sur la planète.)

À la place, elle vous donne un "RESET TIME" dans le fichier, et les lignes qui suivent montrent combien de temps s'est écoulé depuis ce moment. Les temps de "RESET" apparaissent principalement une seule fois au début, parfois cependant ils apparaissent plusieurs fois dans le journal, parfois même en sautant des heures, apparemment de manière aléatoire.

Et comme si cela ne suffisait pas.. Laissez-moi vous montrer un exemple concret:

adb shell dumpsys batterystats

Me donne (parmi d'autres choses bien sûr) ceci:

                0 (9) RESET:TIME: 2020-01-29-01-37-39

Bien. Le temps commence donc à 2020-01-29-01-37-39. D'accord. Un seul temps de reset dans la sortie.

Je viens juste d'allumer l'écran. Voici l'entrée dans le journal pour cela:

      +21h44m19s484ms (4) 057 +wake_lock=1000:"PhoneWindowManager.mPowerKeyWakeLock" +screen screenwake=1000:"android.policy:POWER"

Génial. +21h44m19s. Nous sommes maintenant (enfin, c'était le cas quand cela s'est produit) le 2020-01-30-00-16-00.

Temps de "RESET" de 2020-01-29-01-37-39 + 21h44m19s = 2020-01-29-23-21-58. ?????


D'accord, passons à mes questions réelles:

  1. Pourquoi dumpsys batterystats n'utilise-t-il pas des horodatages normaux?
  2. Comment lit-on ces horodatages? Ils semblent complètement incorrects.
  3. Y a-t-il un moyen de les changer en horodatages "normaux"?

(Mon objectif est de suivre exactement quand l'écran (et éventuellement le WiFi) était allumé et quand il était éteint. Si il y a un autre moyen de le faire en dehors de batterystats, merci de laisser un commentaire.)

2voto

Ceci est une réponse partielle qui a besoin de plus de détails à travers le dump complet pour comprendre ce que cherche à dire le système et lire la sortie de celui-ci.

L'unité de données est un nombre pris dans la liste suivante : 1: Nombre d'objets 2: Nombre d'octets 3: Nombre de millisecondes 4: Nombre d'allocations 5: Id 6: Pourcentage s: Nombre de secondes (temps monotone) La valeur par défaut pour les données de type entier/long est 2 (octets).

Se décompose en ce que je pense être :

L'unité de données est un nombre pris dans la liste suivante :

1: Nombre d'objets = (4)

2: Nombre d'octets {057}

3: Nombre de millisecondes. +21h44m19s484ms wake_lock=1000 screen screenwake=1000

4: Nombre d'allocations wake_lock=1000, screen screenwake=1000

5: Id. android.policy:POWER

6: Pourcentage s: Nombre de secondes (temps monotone) La valeur par défaut pour les données de type entier/long est 2 (octets).

https://android.googlesource.com/platform/system/core/+/master/logcat/event.logtags

La valeur du temps commence au démarrage jusqu'à la valeur actuelle en décomposant le temps en :

+21h44m19s484ms Tout d'abord le temps depuis le démarrage de l'appareil et se lit comme suit :

21h représentant 21 heures.

44m pour 44 minutes

19s pour 19 secondes

484ms pour 484 millisecondes.

Cependant, il y a plus à comprendre car cela se lit ligne par ligne, ce qui signifie qu'une seule ligne ne raconte pas toute l'histoire. Pour comprendre ce qui se passe, le log complet ou le dump est nécessaire.

0 votes

Ma question concerne uniquement les horodatages utilisés (je dois admettre que je suis confus par la première partie de votre réponse, mais ce n'est pas vraiment ce dont je parle de toute façon). Il serait en effet logique que la valeur temporelle commence au démarrage (équivalant à RESET TIME), mais comme je l'ai dit dans ma question, cela ne peut pas vraiment être le cas. Il pourrait être précis au début du journal, mais comme dans mon exemple, il dérive beaucoup vers la fin.

0 votes

Ce n'est pas complet, cela ressemble à la partie cassée du cerveau lit mais donne assez d'informations pour vous dire ce qui se passe. Vous pouvez obtenir des informations plus détaillées et verbeuses à travers une variété d'options ou de types de journaux. Je crois que vous avez un peu de vision tunnellière vous empêchant de voir comment la syntaxe est présentée de manière simple en attendant une réponse ou une raison plus compliquée.

0 votes

Je pense que vous ne comprenez pas ma question.. Je ne parle pas vraiment de la syntaxe du journal, de la verbosité, ou quoi que ce soit de ce genre. Ma question est tout au sujet de "Pourquoi batterystats utilise +*h*m*s*ms au lieu d'un horodatage DATETIME réel?" et pourquoi les heures qu'il utilise ne correspondent pas. Vous voyez, il dira par exemple que l'heure de démarrage et de réinitialisation était à 1h du matin, puis il dira +5h dans le journal, ce qui serait 6h du matin, n'est-ce pas? Sauf qu'en réalité c'était, disons 6h40. C'est de cela que traite ma question. Les heures dans le journal ne correspondent pas avec l'heure réelle.

2voto

A Michael Piper Points 46

La consommation d'énergie des appareils Android est estimée en fonction du temps pendant lequel certains composants matériels se trouvent dans différents états (par exemple, WIFI ON, WIFI OFF, etc.). Pour chaque composant matériel, il existe une valeur de puissance pour chaque état du composant fournie par le fabricant. Ainsi, avec le temps pendant lequel un composant matériel réside dans un certain état multiplié par la valeur de puissance, la consommation réelle d'énergie est calculée.

Chaque fois qu'un changement d'état est déclenché, un événement est enregistré dans l'outil batterystats. L'outil batterystats collecte les événements en fonction d'un horodatage commençant à 0 à l'événement RESET mentionné.

Vos questions:

(1) Les horodatages dans la sortie de batterystats commencent depuis la dernière remise à zéro de l'outil batterystats. Vous pouvez réinitialiser manuellement l'horodatage avec la commande batterystats reset. Je ne sais pas quels sont les déclencheurs exacts à l'intérieur du système Android pour réinitialiser les batterystats, probablement lorsque la batterie est complètement chargée.

(2) Comme vous l'avez mentionné, vous avez l'heure système de l'événement RESET. Vous avez lu l'exemple +21h44m19s: 21 heures 44 minutes et 19 secondes depuis l'événement RESET.

(3) Peu importe ce que vous entendez par "vrais horodatages", vous pouvez les transformer en n'importe quel format de date en ajoutant l'horodatage de batterystats à l'heure de réinitialisation. La sortie de batterystats ne peut pas être modifiée.

0 votes

J'ai essayé d'ajouter les horodatages à l'heure de réinitialisation, mais de nombreuses fois cela ne donne pas de résultats précis (par exemple, parfois un horodatage se retrouve dans le futur ou complètement incorrect)

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X