Free Press

Android Studio har en felsökare som gör att du kan göra bland annat följande:

• Välj en enhet att felsöka din app på.
• Sätt brytpunkter i din Java-, Kotlin- och C/C++-kod.
• Undersök variabler och utvärdera uttryck vid körning.

Den här sidan innehåller anvisningar för grundläggande felsökningsåtgärder. Mer dokumentation finns även i dokumentationen om felsökning i IntelliJ IDEA.

Aktivera felsökning

För att du ska kunna börja felsöka måste du förbereda dig på följande sätt:

• Aktivera felsökning på enheten:

  Om du använder emulatorn är detta aktiverat som standard. Men för en ansluten enhet måste du aktivera felsökning i enhetens utvecklingsalternativ.

• Kör en felsökningsbar byggvariant:

  Du måste använda en byggvariant sominkluderar debuggable true i byggkonfigurationen. Vanligtvis kan du bara välja standardvarianten ”debug” som ingår i alla Android Studio-projekt (även om den inte syns i filen build.gradle). Men om du definierar nya byggtyper som ska kunna debuggas måste du lägga till `debuggable true` till byggtypen:

  android { buildTypes { customDebugType { debuggable true ... } }}

  Denna egenskap gäller även för moduler med C/C++-kod. (Egenskapen jniDebuggable används inte längre.)

  Om din app är beroende av en biblioteksmodul som du också vill felsöka måste det biblioteket också förpackas med debuggable true så att det behåller sina felsökningssymboler.Om du vill försäkra dig om att de felsökningsbara varianterna av ditt app-projekt får den felsökningsbara varianten av en biblioteksmodul, se till att du publicerar andra versioner än standardversioner av ditt bibliotek.

Starta felsökning

Du kan starta en felsökningssession på följande sätt:

1. Sätt några brytpunkter i app-koden.
2. I verktygsfältet väljer du en enhet som du vill felsöka appen på i rullgardinsmenyn för målenhet.

   

   Om du inte har några konfigurerade enheter måste du antingen ansluta en enhet via USB eller skapa en AVD för att använda Android Emulator.

3. I verktygsfältet klickar du på Debug .

   Om du ser en dialogruta som frågar om du vill ”växla från Kör till felsökning” betyder det att din app redan körs på enheten och att den måste startas om för att du ska kunna börja felsöka. Om du hellre vill behålla samma instans av appen som körs klickar du på Avbryt felsökning och kopplar istället felsökaren till en app som körs.

   Annars bygger Android Studio en APK, signerar den med en felsökningsnyckel, installerar den på den valda enheten och kör den. Om du lägger till C- och C++-kod i ditt projekt kör Android Studio även LLDB-debuggern i fönstret Debug för att felsöka den ursprungliga koden.

4. Om fönstret Debug inte är öppet väljer du Visa > Verktygsfönster > Debug (eller klickar på Debug i verktygsfönsterfältet) och klickar sedan på fliken Debugger, som visas i figur 1.

   Figur 1. Fönstret Debugger, som visar den aktuella tråden och objektträdet för en variabel

Ansluta debuggern till en app som körs

Om appen redan körs på enheten kan du börja debugga utan att starta om appen på följande sätt:

1. Klicka på Koppla felsökaren till Android-processen .
2. I dialogrutan Välj process väljer du den process som du vill koppla felsökaren till.

   Om du använder en emulator eller en rotad enhet kan du kryssa i Visa alla processer för att se alla processer.

   I rullgardinsmenyn Använd Android Debugger-inställningar från kan du välja en befintlig kör-/felsökarkonfiguration. (För C- och C++-kod kan du på detta sätt återanvända LLDB:s startkommandon, LLDB-kommandon efter anslutning och symbolkataloger i en befintlig konfiguration). Om du inte har någon befintlig run/debug-konfiguration väljer du Create New (Skapa ny). Detta val aktiverar rullgardinsmenyn Debug Type, där du kan välja en annan debugtyp. Som standard använder Android Studio Auto debug-typ för att välja det bästa felsökningsalternativet för dig, baserat på om ditt projekt innehåller Java- eller C/C++-kod.

3. Klicka på OK.

   Fönstret Debug visas.

Obs: Android Studios debugger och garbage collector är löst integrerade. Den virtuella Android-maskinen garanterar att alla objekt som felsökaren känner till inte samlas in som skräp förrän efter att felsökaren kopplats bort. Detta kan resultera i en uppbyggnad av objekt över tiden medan felsökaren är ansluten. Om felsökaren till exempel ser en pågående tråd samlas det tillhörande Thread-objektet inte in förrän felsökaren kopplar bort, även om tråden har avslutats.

Ändra felsökartyp

Om det krävs olika felsökarverktyg för att felsöka Java/Kotlin-kod och C/C++-kod kan du medAndroid Studio-felsökaren välja vilken felsökartyp du vill använda. Som standard bestämmer Android Studio vilken felsökare som ska användas baserat på vilka språk som upptäcks i ditt projekt (med typenAuto debugger). Du kan dock manuellt välja felsökare i felsökarkonfigurationen (klicka på Run > EditConfigurations) eller i dialogrutan som visas när du klickar på Run > Attach debugger to Androidprocess.

De debug-typer som finns tillgängliga är följande:

Auto Välj den här debug-typen om du vill att Android Studio automatiskt ska välja det bästa alternativet för den kod du debuggar. Om du till exempel har C- eller C++-kod i ditt projekt använder Android Studio automatiskt debugtypen Dual. I annat fall använder Android Studio debugtypen Java. Java Välj den här felsökningstypen om du bara vill felsöka kod som är skriven i Java eller Kotlin – Java-felsökaren ignorerar eventuella brytpunkter eller klockor som du har ställt in i din ursprungliga kod. Native (endast tillgänglig för C/C++-kod) Välj den här felsökningstypen om du vill använda endast LLDB för att felsöka din kod. När du använder den här felsökningstypen är sessionsvyn för Java-debugger inte tillgänglig. Som standard inspekterar LLDB endast din native-kod och ignorerar brytpunkter i din Java-kod. Om du också vill felsöka din Javakod bör du byta till antingen Auto eller Dual debug typ.

Nativ felsökning fungerar endast på enheter som uppfyller följande krav:

• Enheten har stöd för run-as.

  För att kontrollera om enheten har stöd för run-as kör du följande kommando på ADB-skalet som är anslutet till enheten:

  run-as your-package-name pwd

  Ersätt your-package-name med paketnamnet för din app. Om enheten har stöd för run-as bör kommandot återkomma utan några fel.

• Enheten har ptrace aktiverat.

  För att kontrollera om ptrace är aktiverat kör du följande kommando på ADB-skalet som är anslutet till din enhet:

  sysctl kernel.yama.ptrace_scope

  Om ptrace är aktiverat kommer kommandot att skriva ut värdet 0 eller ett unknown key fel. Om ptrace inte är aktiverat kommer det att skriva ut ett annat värde än 0.

Dual (endast tillgänglig med C/C++-kod) Välj den här felsökningstypen om du vill växla mellan felsökning av både Java- och inhemsk kod. Android Studio kopplar både Java-debuggaren och LLDB till din app-process, en för Java-debuggaren och en för LLDB, så att du kan inspektera brytpunkter i både din Java- och infödda kod utan att starta om appen eller ändra din debugkonfiguration.

I figur 2 lägger du märke till de två flikarna till höger om Debug-fönstrets titel. Eftersom appen har både Java- och C++-kod är en flik avsedd för felsökning av den infödda koden och den andra för felsökning av Javakod, vilket anges med -java.

Figur 2. Fliken för felsökning av inhemsk kod och fliken för felsökning av Javakod

Obs: Om du felsöker inhemsk kod som optimerats av kompilatorn kan du få följande varningsmeddelande: This function was compiled with optimizations enabled. Some debugger features may not be available. När du använder optimeringsflaggor, t.ex. -O-flaggor, gör kompilatorn ändringar i din kompilerade kod för att få den att köras effektivare. Detta kan leda till att felsökaren rapporterar oväntad eller felaktig information eftersom det är svårt för felsökaren att mappa den optimerade kompilerade koden tillbaka till den ursprungliga källkoden. Av den här anledningen bör du inaktivera kompileroptimeringar när du felsöker din ursprungliga kod.

Använd systemloggen

Systemloggen visar systemmeddelanden när du felsöker din app. Dessa meddelanden innehåller information från appar som körs på enheten. Om du vill använda systemloggen för att felsöka din app ska du se till att din kod skriver loggmeddelanden och skriver ut stacktrace för undantag medan appen är i utvecklingsfasen.

Skriv loggmeddelanden i din kod

Om du vill skriva loggmeddelanden i din kod använder du klassen Log. Loggmeddelanden hjälper dig att förstå exekveringsflödet genom att samla in systemets felsökningsutdata medan du interagerar med din app. Loggmeddelanden kan tala om för dig vilken del av din applikation som misslyckades. Mer information om loggning finns i Skriva och visa loggar.

Följande exempel visar hur du kan lägga till loggmeddelanden för att avgöra om tidigare tillståndsinformation är tillgänglig när aktiviteten startar:

Under utvecklingen kan koden också fånga upp undantag och skriva stacktrace till systemloggen:

Notera: Ta bort felsökningsloggmeddelanden och utskriftsanrop för stacktrace frånkoden när du är redo att publicera din app. Du kan göra detta genom att ställa in en DEBUGflagga och placera felsökningsloggmeddelanden i villkorliga påståenden.

Visa systemloggen

Du kan visa och filtrera felsökningsmeddelanden och andra systemmeddelanden i Logcat-fönstret. Du kan till exempel se meddelanden när skräpplockning sker eller meddelanden som du lägger till i din app med klassen Log.

För att använda Logcat startar du felsökningen och väljer fliken Logcat i den nedre verktygsfältet enligt figur 3.

Figur 3. Logcat-fönster med filterinställningar

För en beskrivning av logcat och dess filteralternativ, se Skriv och visa loggar med Logcat.

Arbeta med brytpunkter

Android Studio har stöd för flera typer av brytpunkter somutlöser olika felsökningsåtgärder. Den vanligaste typen är en linjebrytpunkt som pausar exekveringen av din app vid en angiven kodrad. När du pausar kan du undersöka variabler, utvärdera uttryck och sedan fortsätta utförandet rad för rad för att fastställa orsakerna till körtidsfel.

För att lägga till en linjebrytpunkt går du tillväga på följande sätt:

1. Placera den kodrad där du vill pausa utförandet och klicka sedan antingen på den vänstra rännan längs med den kodraden eller placera careten på linjen och tryck på Control+F8 (på Mac, Command+F8).
2. Om din app redan är igång behöver du inte uppdatera den för att lägga till pauspunkten – klicka bara på Attach debugger to Android proccess . Annars startar du felsökningen genom att klicka på Debug .

Figur 3. En röd punkt visas bredvid linjen när du ställer in en brytpunkt

När din kodkörning når brytpunkten pausar Android Studio körningen av din app. Du kan sedan använda verktygen på fliken Debugger för att identifiera appens tillstånd:

• Om du vill undersöka objektträdet för en variabel expanderar du den i vyn Variables (Variabler). Om vyn Variabler inte är synlig klickar du på Återställ variabelvyn .

• Om du vill utvärdera ett uttryck vid den aktuella exekveringspunkten klickar du på Utvärdera uttryck .

• Om du vill gå vidare till nästa rad i koden (utan att ange en metod) klickar du på Steg över .

• För att gå vidare till den första raden inne i ett metodanrop klickar du på Step Into .

• För att gå vidare till nästa rad utanför den aktuella metoden klickar du på Step Out .

• För att fortsätta att köra programmet normalt klickar du på Resume Program .

Om ditt projekt använder någon inhemsk kod kopplar Auto debug-typ som standard både Java-debugger och LLDB till din app som två separata processer, så att du kan växla mellan att inspektera Java- och C/C++-brytpunkter utan att starta om appen eller ändra inställningar.

Observera: För att Android Studio ska kunna upptäcka brytpunkter i din C- eller C++-kod måste du använda en debug-typ som har stöd för LLDB, till exempel Auto, Native eller Dual. Du kan ändra den debug-typ som Android Studio använder genom att redigera din debug-konfiguration. Om du vill veta mer om de olika debugtyperna kan du läsa avsnittet om användning av andra debugtyper.

När Android Studio distribuerar appen till måttenheten öppnas fönstret Debug med en flik eller debugsessionsvy för varje debuggerprocess, som visas i figur 4.

Figur 4. Debuggning av inhemsk kod med LLDB

1. Android Studio växlar till fliken <din-modul> när LLDB-debuggaren stöter på en brytpunkt i din C/C++-kod. Fönstren Frames, Variables och Watches är också tillgängliga och fungerar precis som de skulle göra om du debuggar Java-kod. Även om fönstret Threads inte är tillgängligt i LLDB-sessionsvyn kan du komma åt dina app-processer med hjälp av rullgardinslistan i fönstret Frames. Du kan läsa mer om de här rutorna i avsnitten om hur du debuggar fönsterramar och inspekterar variabler.

   Obs: När du inspekterar en brytpunkt i din ursprungliga kod avbryter Android-systemet den virtuella maskinen som kör appens Java-bytecode. Detta innebär att du inte kan interagera med Java-felsökaren eller hämta någon tillståndsinformation från din Java-felsökarsession medan du inspekterar en brytpunkt i din infödda kod.

2. Android Studio växlar till fliken <din-modul>-java när Java-debuggern hittar en brytpunkt i din Javakod.
3. När du felsöker med LLDB kan du använda LLDB-terminalen i LLDB-sessionsvyn för att skicka kommandoradsalternativ till LLDB. Om du har vissa kommandon som du vill att LLDB ska utföra varje gång du börjar felsöka din app, antingen strax före eller strax efter att felsökaren ansluter sig till app-processen, kan du lägga till dessa kommandon i din felsökarkonfiguration.

När du debuggar C/C++-kod kan du också ställa in speciella typer av brytpunkter, så kallade watchpoints, som kan avbryta din app-process när din app interagerar med ett visst minnesblock. Om du vill veta mer läser du avsnittet om hur du lägger till watchpoints.

Visa och konfigurera brytpunkter

Om du vill visa alla brytpunkter och konfigurera inställningar för brytpunkterna klickar du på Visa brytpunkter till vänster i fönstret Debug. Fönstret Brytpunkter visas, enligt figur 5.

Figur 5. Fönstret Brytpunkter listar alla aktuella brytpunkter och innehåller beteendeinställningar för varje

I fönstret Brytpunkter kan du aktivera eller inaktivera varje brytpunkt från listan till vänster. Om en brytpunkt är inaktiverad pausar Android Studio inte din app när den träffar den brytpunkten. Välj en brytpunkt i listan för att konfigurera dess inställningar. Du kan konfigurera en brytpunkt så att den först är inaktiverad och att systemet aktiverar den när en annan brytpunkt nås. Du kan också konfigurera om en brytpunkt ska inaktiveras efter att den har träffats. Om du vill ställa in en brytpunkt för ett undantag väljer du Brytpunkter för undantag i listan över brytpunkter.

Ramar i fönstret Debugger

I fönstret Debugger kan du i fönstret Ramar inspektera den stackram som orsakade att den aktuella brytpunkten träffades. Detta gör att du kan navigera och undersöka stackramen och även inspektera listan över trådar i din Android-app. Om du vill välja en tråd använder du rullgardinsmenyn för trådval och visar dess stackram. Om du klickar på elementen i ramen öppnas källan i redigeraren. Du kan också anpassa trådpresentationen och exportera stapelramen som diskuteras i guiden Fönsterramar.

Inspektera variabler

I fönstret Debugger kan du med fönstret Variabler inspektera variabler när systemet stoppar appen på en brytpunkt och du väljer en ram från fönstret Ramar. I rutan Variabler kan du också utvärdera ad hoc-uttryck med hjälp av statiska metoder och/eller variabler som är tillgängliga i den valda ramen.

Rutan Bevakningar ger liknande funktionalitet förutom att de uttryck som läggs till i rutan Bevakningar finns kvar mellan felsökningssessioner. Du bör lägga till bevakningar för variabler och fält som du har tillgång till ofta eller som tillhandahåller tillstånd som är till hjälp för den aktuella felsökningssessionen. Fönstren Variables och Watches visas enligt figur 5.

För att lägga till en variabel eller ett uttryck i listan Watches följer du de här stegen:

1. Begynna felsökning.
2. I fönstret Watches klickar du på Lägg till .
3. I textrutan som visas skriver du namnet på den variabel eller det uttryck som du vill övervaka och trycker sedan på Enter.

Om du vill ta bort ett objekt från listan Bevakningar markerar du objektet och klickar sedan på Ta bort .

Du kan ändra ordningen på elementen i listan Bevakningar genom att markera ett objekt och sedan klicka på Upp eller Ner .

Figur 6. Fönstren Variables och Watches i fönstret Debugger

Lägg till watchpoints

När du debuggar C/C++-kod kan du ställa in speciella typer av brytpunkter, så kallade watchpoints, som kan avbryta app-processen när appen interagerar med ett visst minnesblock. Om du till exempel ställer in två pekare till ett minnesblock och tilldelar en bevakningspunkt till det, utlöses bevakningspunkten om du använder någon av pekarna för att komma åt minnesblocket.

I Android Studio kan du skapa en bevakningspunkt under körning genom att välja en specifik variabel, men LLDB tilldelar bevakningspunkten endast det minnesblock som systemet allokerar till den variabeln, inte själva variabeln. Detta skiljer sig från att lägga till en variabel i rutan Watches, vilket gör att du kan observera värdet på en variabel, men du kan inte avbryta app-processen när systemet läser eller ändrar dess värde i minnet.

Observera: När din app-process avslutar en funktion och systemet avallokerar sina lokala variabler från minnet måste du omfördela alla bevakningspunkter som du har skapat för dessa variabler.

För att ställa in en bevakningspunkt måste du uppfylla följande krav:

• Din fysiska måttenhet eller emulator använder en x86- eller x86_64-processor. Om enheten använder en ARM-CPU måste du anpassa gränsen för variabelns adress i minnet till antingen 4 byte för 32-bitars processorer eller 8 byte för 64-bitars processorer. Du kan justera en variabel i din ursprungliga kod genom att ange __attribute__((aligned(num_bytes))) i variabelfördröjningen, som visas nedan:

  // For a 64-bit ARM processorint my_counter __attribute__((aligned(8)));

• Du har redan tilldelat tre eller färre watchpoints. Android Studio stöder endast upp till fyra watchpoints på x86- eller x86_64-målenheter. Andra enheter kan ha stöd för färre watchpoints.

Observera: När du felsöker din app med 32-bitars ARM ABIs kan det orsaka en krasch om du lägger till en watchpoint eller håller dig över variabler i koden för att undersöka deras värden. Som en lösning kan du debugga med 64-bitars ARM, x86 eller x86_64 binärer. Det här problemet kommer att åtgärdas i en kommande version av Android Studio.

Om du uppfyller kraven ovan kan du lägga till en bevakningspunkt på följande sätt:

1. När appen är avbruten på en brytpunkt, navigerar du till fönstret Variables (Variabler) i LLDB-sessionsvyn.

2. Högerklicka på en variabel som upptar minnesblocket som du vill spåra och välj Lägg till bevakningspunkt. En dialogruta för att konfigurera din bevakningspunkt visas, enligt figur 7.

   

   Figur 7. Lägg till en bevakningspunkt till en variabel i minnet

3. Konfigurera din bevakningspunkt med följande alternativ:
   • Aktiverad: Du kan avmarkera det här alternativet om du vill att Android Studio ska ignorera watchpointet för tillfället. Android Studio sparar fortfarande din bevakningspunkt så att du kan komma åt den senare i din felsökningssession.
   • Suspend: Som standard avbryter Android-systemet din app-process när den får tillgång till ett minnesblock som du tilldelar en bevakningspunkt. Du kan avmarkera det här alternativet om du inte vill ha det här beteendet – detta visar ytterligare alternativ som du kan använda för att anpassa beteendet när systemet interagerar med din watchpoint: Loggningsmeddelande till konsolen och Ta bort när den träffas.
   • Åtkomsttyp: Välj om din app ska utlösa din watchpoint när den försöker läsa eller skriva till det minnesblock som systemet allokerar till variabeln. Om du vill utlösa din bevakningspunkt vid antingen läsning eller skrivning väljer du Alla.
4. Klicka på Klar.

Om du vill visa alla dina övervakningspunkter och konfigurera övervakningspunkternas inställningar klickar du på Visa brytpunkter på vänster sida av fönstret Debug. Dialogrutan Brytpunkter visas, enligt figur 8.

Figur 8. Dialogrutan Brytpunkter listar dina aktuella bevakningspunkter och innehåller beteendeinställningar för varje

När du har lagt till din bevakningspunkt klickar du på Återuppta program på vänster sida av fönstret Debug för att återuppta app-processen. Om din app försöker komma åt ett minnesblock som du har ställt in en bevakningspunkt för, avbryter Android-systemet som standard din app-process och en ikon för en bevakningspunkt visas bredvid den kodrad som din app utförde senast, vilket visas i figur 9.

Figur 9. Android Studio visar den kodrad som din app exekverar precis innan den utlöser en watchpoint

Visa och ändra visningsformat för resursvärden

I felsökningsläget kan du visa resursvärden och välja ett annat visningsformat för variabler i din Javakod. När fliken Variabler visas och en ram är markerad gör du följande:

1. I listan Variabler högerklickar du var som helst på en resursrad för att visa rullgardinslistan.
2. I rullgardinslistan väljer du Visa som och väljer det format du vill använda.

   De tillgängliga formaten beror på datatypen för den resurs du valt. Du kan se ett eller flera av följande alternativ:

   • Klass:
   • toString: Visa klassdefinitionen: Visa strängformat.
   • Object:
   • Array: Visa objektdefinitionen (en instans av en klass).
   • Array: Visa objektdefinitionen (en instans av en klass): Visa i ett array-format.
   • Timestamp:
   • Auto: Android Studio väljer det bästa formatet baserat på datatypen.
   • Binary: Visa datum och tid enligt följande: yyyy-mm-dd hh:mm:ss.
   • Auto: Android Studio väljer det bästa formatet baserat på datatypen.
   • Binary: Visa datum och tid i följande format: Visa ett binärt värde med nollor och ettor.
   • MeasureSpec: Värde: Det värde som överförs från föräldern till det valda barnet. Se MeasureSpec.
   • Hex:
   • Primitiv: Visa som ett hexadecimalt värde.
   • Primitiv:
   • Integer: Visas som ett numeriskt värde med hjälp av en primitiv datatyp.
   • Integer:

Du kan skapa ett anpassat format (datatypsrenderare) enligt följande: