Androidin lokianalyysi

Android-kehittäjänä kaikki tietävät, että lokianalyysi on kehitysvaihe, ja törmäämme siihen aika ajoin.
Mutta lokianalyysi on tärkein haastava asia koodin ylläpitäjälle tai tuki-insinöörille.

Kun jokin Android-tuote lanseerataan markkinoille ja asiakkaat alkavat käyttää sitä. Sitten todellinen skenaario vikoja / ongelmia alkaa tulla ja se on tärkein tehtävä Support Engineer / projektin ylläpito insinööri analysoida Bug / ongelma annettujen joukko lokit.

Aluksi aloitamme Android-ekosysteemissä käytettävissä olevien lokien tyypistä: –

• Sovellusloki
• Järjestelmäloki
• Tapahtumaloki
• Radioloki

Androidin lokijärjestelmä koostuu seuraavista:

• ytimen ajuri ja ytimen puskurit lokiviestien tallentamiseen
• C-, C++- ja Java-luokat lokimerkintöjen tekemiseen ja lokiviestien käyttämiseen.
• Logcat (itsenäinen ohjelma lokiviestien katseluun )
• DDMS (kyky katsella ja suodattaa lokiviestejä isäntäkoneelta)

Androidin lokipuskuri/kontti

• main – sovelluksen pääasiallinen loki
• events – systeemitapahtumatietoja varten
• radio – radio- ja puhelin-liittyvät tiedot
• system – loki matalan tason järjestelmäviestejä ja virheenkorjausta varten

Mitä lokiviesti sisältää:-

Jokainen lokiviesti koostuu

• Tunnisteesta, joka osoittaa, mistä järjestelmän tai sovelluksen osasta viesti on tullut
• Aikaleimasta (mihin aikaan tämä viesti on tullut)
• Viesteistä. viestin lokitaso (tai viestin edustaman tapahtuman prioriteetti) ja
• itse lokiviesti (yksityiskohtainen kuvaus virheestä tai poikkeuksesta tai tiedosta jne.)

Mitä kukin lokityyppi sisältää:-

1. Sovellusloki

• käyttää android.util.Log-luokan metodeja kirjoittaaksesi eri prioriteetin omaavia viestejä lokiin
• Java-luokat ilmoittavat tunnisteensa staattisesti merkkijonona, jonka ne välittävät log-metodille
• Käytetty log-metodi ilmoittaa viestin ”vakavuuden” (tai lokin tason)
• Viestejä voidaan suodattaa tunnisteen tai prioriteetin mukaan, kun lokeja käsitellään hakutyökaluilla (logcat)

2. Järjestelmäloki

• Käyttää android.util.Slog-luokkaa kirjoittaaksesi eri prioriteetilla olevan viestin siihen liittyvine viesteineen
• Monet Android-kehysluokat käyttävät järjestelmälokia pitääkseen viestinsä erillään (mahdollisesti hälyttävistä) sovelluslokin viesteistä
• Muotoiltu viesti toimitetaan C/C++-kirjaston kautta alas kernelajurille, joka tallentaa viestin sopivaan puskuriin(system buffer)

3. Tapahtumaloki

• Tapahtumalokiviestit luodaan käyttämällä android.util.EventLog-luokkaa, joka luo binäärimuotoisia lokiviestejä.
• Lokimerkinnät koostuvat binäärisistä tag-koodeista, joita seuraavat binääriset parametrit.
• Viestin tag-koodit tallennetaan järjestelmään osoitteeseen: /system/etc/event-log-tags.
• Kussakin viestissä on lokiviestin merkkijono sekä koodit, jotka osoittavat kyseiseen merkintään liittyvät (tallennetut) arvot.

4. Radioloki

• Käytetään radioon ja puhelimeen (modeemiin) liittyviin tietoihin
• Lokimerkinnät koostuvat binääritunnisteiden koodista ja viestistä Verkkotietoja varten
• Logijärjestelmä ohjaa tietyillä tunnisteilla varustettuja viestejä automaattisesti radiolokin puskuriin

Lokin formaatti Androidissa

jäljempänä on yleinen lokin tiedostoformaatti androidissa

tv_sec tv_nsec priority pid tid tag messageLen Message

tunniste: log tag
tv_sec & tv_nsec: lokiviestien aikaleima
pid: prosessin id, josta lokiviestit tulevat
tid: säikeen id
Priority-arvo on jokin seuraavista merkkiarvoista, järjestyksessä pienimmästä korkeimpaan prioriteettiin:
V – Verbose (alhaisin prioriteetti)*
D – Debug*
I – Info*
W – Warning*
E – Error*
F – Fatal*
S – Silent (korkein prioriteetti, jolle ei koskaan tulosteta mitään)

Log-tiedostojen sijainnit
On olemassa useita hakemistoja, joissa lokitiedostot tallentuvat (mukaan lukien kaatumisten yhteydessä syntyvät lokitiedostot), ja ne eivät ole vakioidut(i.ts. jotkut voivat olla ROM-kohtaisia). Laitan joitakin yhteisiä tänne.

• /data/anr : Dalvik kirjoittaa stack traces tänne ANR:ään, ts. ”Application Not Responding” aka ”Force-Close”
• /data/dontpanic : Sisältää joitain kaatumislokeja, mukaan lukien traces
• /data/kernelpanics :- Säilyttää ”kernel paniciin” liittyvät lokit
• /data/tombstones :- voi sisältää useita tombstone_nn -tiedostoja (nn on numero 0-10 ja 10:n jälkeen toistetaan uudelleen)

’Log’ komentorivityökalu
Lokien kaappaamiseksi android-laitteista/emulaattorista Alla on komentorityökalu. Tosielämän projekteissa on lokien kaappaussovelluksia/työkaluja, joita käytetään käyttäjän laitteen lokien kaappaamiseen ja niiden jakamiseen takaisin kehittäjälle/ylläpitäjälle analysointia varten.

• adb logcat (näyttää kaikki tyypin lokit nykyiselle android-järjestelmälle
• adb logcat -v threadtime (se sisältää päivämäärän ja kellonajan)
• adb logcat -v threadtime > lokitiedosto.txt (Tallentaa lokit lokitiedostoon logfile.txt)

Käyttökelpoiset suodatinmallit
Lokeja suodattaa alla olevalla suodattimella, joka voidaan käyttää mainituissa komennossa. Voit myös käyttää tätä suodatinta etsiessäsi lokitiedostoa(käyttäjän laitteen toimittamat lokit).

• adb logcat -f <output_file> Tallenna kaikki lokit tiedostoon
• adb logcat ”*:E” Hae kaikki virhetilanteet ja virheet
• adb logcat | grep -i ”foo.example.” #hae kaikki lokit, jotka liittyvät ”foo.example.*” tagname
• adb logcat ”application_or_tag_name:*” ”*:S” Hae kaikki lokit sovelluksen nimen mukaan
• adb logcat -b events ”gsm_service_state_change” ”*:S” Hae kaikki GSM-tilan muutokset
• adb logcat -b radio Hae kaikki radiotapahtumat

Login analyysi
Tämänhetkiseen tilanteeseen mennessä saimme Androidin lokijärjestelmän perustavanlaatuisen paljastuksen. Nyt on aika analysoida sovelluksestasi tai loppukäyttäjältäsi tulevat lokit. Tässä voimme jakaa lokianalyysin kahteen osaan

1. Debug Log: – Kehitys- ja testausvaiheessa tulevat lokitiedostot
2. Production Log: – Suoraan loppukäyttäjältä tulevat lokitiedostot.

Arvaa siis, kumpi niistä on hankala Production one Right? Mikä on siis paras lähestymistapa debuggaamiseen ja halutun tiedon saamiseen kaapatuista lokitiedostoista? Kuten olen keskustellut edellä, Voimme tehdä sen käyttämällä

• ”Hyödyllisiä suodatuskuvioita” ja
• Käyttämällä jotakin työkalua (esimerkki LogRabit, GoogleLogTool ja SonyLogTool)

Viimeiseksi Android-lokianalyysi on siis jatkuvaa oppimista ja kokemuksesi prosessin hyödyntämistä. Henkilökohtaisesti analysoin lokit asiaankuuluvan suodattimen ja työkalun kautta aiemmalla kokemuksellani.

Mutta yksi asia on hyvä Jokainen Android-analyysi (loppukäyttäjän ongelma/vikapäiväkirja) antaa sinulle uutta oppimista ja kokemusta. Joten jatka sitä tekemistä ja nauti elämästäsi android-järjestelmän koodaajana ja ylläpitäjänä😎😎😎😎