Android Studio biedt een debugger die u in staat stelt om het volgende en meer te doen:
- Selecteer een apparaat om uw app op te debuggen.
- Breekpunten instellen in uw Java-, Kotlin- en C/C++-code.
- Variabelen onderzoeken en expressies evalueren tijdens runtime.
Deze pagina bevat instructies voor basisbewerkingen van de debugger. Voor meer documentatie, zie ook de IntelliJ IDEA debugging docs.
- Bugging inschakelen
- Start debugging
- Koppel de debugger aan een draaiende app
- Wijzig het debugger type
- Gebruik het systeemlog
- Logberichten in uw code schrijven
- Bekijk het systeemlog
- Werken met onderbrekingspunten
- Onderbrekingspunten bekijken en configureren
- Debug venster frames
- Variabelen inspecteren
- Watchpoints toevoegen
- Weergave-indeling voor resourcewaarden bekijken en wijzigen
Bugging inschakelen
Voordat u kunt beginnen met debuggen, moet u zich als volgt voorbereiden:
- Bugging op uw apparaat inschakelen:
Als u de emulator gebruikt, is dit standaard ingeschakeld. Maar voor een aangesloten apparaat moet u debugging inschakelen in de ontwikkelaarsopties van het apparaat.
- Voer een debuggable build-variant uit:
U moet een build-variant gebruiken die
debuggable true
in de build-configuratie bevat. Normaal gesproken kunt u gewoon de standaard “debug” variant selecteren die is opgenomen in elk Android Studio project (ook al is deze niet zichtbaar in hetbuild.gradle
bestand). Maar als u nieuwe build types definieert die debuggable moeten zijn, moet u `debuggable true` toevoegen aan het build type:android { buildTypes { customDebugType { debuggable true ... } }}
Deze eigenschap is ook van toepassing op modules met C/C++ code. (De
jniDebuggable
eigenschap wordt niet langer gebruikt.)Als uw app afhankelijk is van een bibliotheekmodule die u ook wilt debuggen, moet die bibliotheek ook worden verpakt met
debuggable true
zodat het zijn debug-symbolen behoudt.Om ervoor te zorgen dat de debuggable varianten van uw app-project de debuggable variant van een bibliotheekmodule ontvangen, moet u ervoor zorgen dat u niet-default versies van uw bibliotheek publiceert.
Start debugging
U kunt een debug-sessie als volgt starten:
- Stel enkele breekpunten in de app code in.
- Selecteer in de werkbalk een apparaat om uw app op te debuggen uit het doelapparaat drop-down menu.
Als u geen apparaten hebt geconfigureerd, dan moet u ofwel een apparaat via USB aansluiten of een AVD maken om de Android Emulator te gebruiken.
- In de werkbalk, klik op Debug .
Als u een dialoogvenster ziet waarin u wordt gevraagd of u wilt “overschakelen van Uitvoeren naar Debuggen”, betekent dit dat uw app al op het apparaat draait en dat deze opnieuw moet worden opgestart om te beginnen met debuggen. Als u liever dezelfde instantie van de app draaiende houdt, klikt u op Annuleren Debug en in plaats daarvan koppelt u de debugger aan een draaiende app.
Anders, Android Studio bouwt een APK, ondertekent het met een debug-sleutel, installeert het op uw geselecteerde apparaat, en voert het uit. Als u C en C + + code toe te voegen aan uw project, Android Studio draait ook de LLDB debugger in het Debug-venster om uw native code te debuggen.
- Als het Debug-venster niet is geopend, selecteert u View > Tool Windows > Debug (of klikt u op Debug in de werkvensterbalk), en klikt u vervolgens op het tabblad Debugger, zoals getoond in figuur 1.
Figuur 1. Het Debugger-venster, dat de huidige thread en de objectboom voor een variabele toont
Koppel de debugger aan een draaiende app
Als uw app al op uw apparaat draait, kunt u als volgt beginnen met debuggen zonder uw app opnieuw te starten:
- Klik op Debugger koppelen aan Android-proces .
- In het dialoogvenster Kies proces selecteert u het proces waaraan u de debugger wilt koppelen.
Als u een emulator of een geroote apparaat gebruikt, kunt u Toon alle processen aanvinken om alle processen te zien.
In het vervolgkeuzemenu Gebruik Android Debugger-instellingen van kunt u een bestaande run/debug-configuratie selecteren. (Voor C en C++ code, dit laat u de LLDB opstart commando’s, LLDB post-attach commando’s, en symbool directories hergebruiken in een bestaande configuratie). Als u geen bestaande run/debug-configuratie hebt, selecteert u Nieuw maken. Deze selectie schakelt het vervolgkeuzemenu Debugtype in, waar u een ander debugtype kunt selecteren. Standaard gebruikt Android Studio het debugtype Auto om de beste debuggeroptie voor u te selecteren, op basis van of uw project Java- of C/C++ code bevat.
- Klik op OK.
Het Debug-venster verschijnt.
Opmerking: De Android Studio debugger en garbage collector zijn losjes geïntegreerd. De Android virtuele machine garandeert dat elk object waar de debugger zich bewust van is niet wordt garbage collected tot na de debugger de verbinding verbreekt. Dit kan resulteren in een opeenhoping van objecten na verloop van tijd terwijl de debugger is aangesloten. Bijvoorbeeld, als de debugger een lopende thread ziet, wordt het bijbehorende Thread
-object niet verzameld totdat de debugger de verbinding verbreekt, zelfs als de thread is beëindigd.
Wijzig het debugger type
Omdat verschillende debugger tools nodig zijn om Java/Kotlin code en C/C++ code te debuggen, staat deAndroid Studio debugger u toe om te selecteren welk debugger type te gebruiken. Standaard bepaalt Android Studio welke debugger moet worden gebruikt op basis van welke talen het detecteert in uw project (met hetAuto debugger type). U kunt echter handmatig de debugger selecteren in de debug-configuratie (klik op Uitvoeren >Configuraties bewerken) of in het dialoogvenster dat verschijnt wanneer u klikt op Uitvoeren > Debugger koppelen aan Androidproces.
De beschikbare debug types zijn onder andere de volgende:
Auto Selecteer dit debug type als u wilt dat Android Studio automatisch de beste optie kiest voor de code die u aan het debuggen bent. Bijvoorbeeld, als u C of C++ code in uw project hebt, gebruikt Android Studio automatisch het Dual debug type. Anders gebruikt Android Studio het Java debug-type. Java Selecteer dit debugtype als u alleen code wilt debuggen die is geschreven in Java of Kotlin-de Java debugger negeert eventuele breakpoints of watches die u hebt ingesteld in uw native code. Native (enkel beschikbaar met C/C++ code) Selecteer dit debugtype als je enkel LLDB wil gebruiken om je code te debuggen. Wanneer u dit debugtype gebruikt, is de Java debugger session view niet beschikbaar. Standaard inspecteert LLDB enkel uw native code en negeert het breekpunten in uw Java code. Als u ook uw Java-code wilt debuggen, moet u overschakelen naar het debuggingstype Auto of Dual.
Native debugging werkt alleen op apparaten die aan de volgende eisen voldoen:
-
Het apparaat ondersteunt
run-as
.Om te controleren of het apparaat
run-as
ondersteunt, voert u het volgende commando uit op de ADB-shell die is verbonden met uw apparaat:run-as your-package-name pwd
Vervang
your-package-name
door de pakketnaam van uw app. Als het apparaatrun-as
ondersteunt, zou het commando zonder fouten moeten terugkomen. -
Het apparaat heeft
ptrace
ingeschakeld.Om te controleren of
ptrace
is ingeschakeld, voert u het volgende commando uit op de ADB-shell die met uw apparaat is verbonden:sysctl kernel.yama.ptrace_scope
Als
ptrace
is ingeschakeld, zal het commando de waarde0
of eenunknown key
-fout afdrukken. Alsptrace
niet is ingeschakeld, wordt een andere waarde dan0
afgedrukt.
Dual (alleen beschikbaar met C/C++ code) Selecteer dit debug-type als u wilt schakelen tussen het debuggen van zowel Java- als native code. Android Studio koppelt zowel de Java debugger en LLDB aan uw app proces, een voor de Java debugger en een voor LLDB, zodat u breakpoints kunt inspecteren in zowel uw Java als native code zonder uw app opnieuw te starten of uw debug configuratie te wijzigen.
In figuur 2 ziet u de twee tabbladen rechts van de titel van het Debug-venster. Omdat de app zowel Java als C++ code bevat, is het ene tabblad voor het debuggen van de native code, en het andere voor het debuggen van Java code, zoals aangegeven met -java.
Figuur 2. Tabblad voor het debuggen van native code en tabblad voor het debuggen van Java code
Opmerking: Als u native code debugt die door de compiler is geoptimaliseerd, kunt u het volgende waarschuwingsbericht krijgen: This function was compiled with optimizations enabled. Some debugger features may not be available
. Wanneer u optimaliseringsvlaggen gebruikt, zoals -O
-vlaggen, brengt de compiler wijzigingen aan in uw gecompileerde code om deze efficiënter te laten werken. Dit kan ertoe leiden dat de debugger onverwachte of onjuiste informatie rapporteert, omdat het moeilijk is voor de debugger om de geoptimaliseerde gecompileerde code terug te koppelen naar de oorspronkelijke broncode. Om deze reden moet u de optimalisaties van de compiler uitschakelen tijdens het debuggen van uw native code.
Gebruik het systeemlog
Het systeemlog toont systeemberichten terwijl u uw app debugt. Deze berichten bevatten informatie van apps die op het apparaat worden uitgevoerd. Als u het systeemlogboek wilt gebruiken om uw app te debuggen, moet u ervoor zorgen dat uw code logberichten schrijft en de stacktrace voor uitzonderingen afdrukt terwijl uw app zich in de ontwikkelingsfase bevindt.
Logberichten in uw code schrijven
Om logberichten in uw code te schrijven, gebruikt u de klasse Log
. Logberichten helpen u de uitvoeringsstroom te begrijpen door de debuguitvoer van het systeem te verzamelen terwijl u met uw app werkt. Logberichten kunnen u vertellen welk deel van uw toepassing is mislukt. Zie Logs schrijven en weergeven voor meer informatie over loggen.
Het volgende voorbeeld laat zien hoe u logberichten kunt toevoegen om te bepalen of eerdere statusinformatie beschikbaar is wanneer uw activiteit start:
Tijdens de ontwikkeling kan uw code ook uitzonderingen opvangen en de stack trace naar het systeemlog schrijven:
Note: Verwijder debug-logberichten en stack trace-afdrukoproepen uit uw code wanneer u klaar bent om uw app te publiceren. U kunt dit doen door een DEBUG
flag in te stellen en debug-logberichten in voorwaardelijke verklaringen te plaatsen.
Bekijk het systeemlog
U kunt debug- en andere systeemberichten in het Logcat-venster bekijken en filteren. U kunt bijvoorbeeld berichten zien wanneer garbage collection optreedt, of berichten die u aan uw app toevoegt met de Log
klasse.
Om logcat te gebruiken, start u debugging en selecteert u het tabblad Logcat in de onderste werkbalk, zoals weergegeven in figuur 3.
Figuur 3. Logcat-venster met filterinstellingen
Voor een beschrijving van logcat en de filteropties ervan, zie Logs schrijven en bekijken met Logcat.
Werken met onderbrekingspunten
Android Studio ondersteunt verschillende typen onderbrekingspunten die verschillende debug-acties triggeren. Het meest voorkomende type is een regelonderbrekingspunt dat de uitvoering van uw app op een gespecificeerde regel code onderbreekt. Terwijl gepauzeerd, kunt u variabelen onderzoeken, expressies evalueren en vervolgens de uitvoering regel voor regel voortzetten om de oorzaken van runtime-fouten te bepalen.
Om een regelonderbrekingspunt toe te voegen, gaat u als volgt te werk:
- Localiseer de regel code waar u de uitvoering wilt pauzeren, klik vervolgens op de linkergoot langs die regel code of plaats de caret op de regel en druk op Control+F8 (op de Mac, Command+F8).
- Als uw app al draait, hoeft u deze niet bij te werken om het breekpunt toe te voegen – klik gewoon op Debugger aan Android-proces koppelen . Anders, start debuggen door te klikken op Debug .
Figuur 3. Er verschijnt een rode stip naast de regel wanneer u een breekpunt instelt
Wanneer de uitvoering van uw code het breekpunt bereikt, pauzeert Android Studio de uitvoering van uw app. U kunt dan de hulpmiddelen in het tabblad Debugger gebruiken om de toestand van de app te identificeren:
-
Om de objectboom voor een variabele te onderzoeken, vouwt u deze uit in de weergave Variabelen. Als de Variabelenweergave niet zichtbaar is, klikt u op Variabelenweergave herstellen .
-
Om een uitdrukking op het huidige uitvoeringspunt te evalueren, klikt u op Uitdrukking evalueren .
-
Om naar de volgende regel in de code te gaan (zonder een methode in te voeren), klikt u op Stap over .
-
Om naar de eerste regel binnen een methode-oproep te gaan, klikt u op Step Into .
-
Om naar de volgende regel buiten de huidige methode te gaan, klikt u op Step Out .
-
Om de normale uitvoering van de app voort te zetten, klikt u op Resume Program .
Als uw project native code gebruikt, koppelt het debugtype Auto standaard zowel de Java-debugger als LLDB aan uw app als twee afzonderlijke processen, zodat u kunt schakelen tussen het inspecteren van Java en C/C++ breekpunten zonder uw app opnieuw te starten of instellingen te wijzigen.
Opmerking: Voor Android Studio om breekpunten in uw C of C++ code te detecteren, moet u een debugtype gebruiken dat LLDB ondersteunt, zoals Auto, Native, of Dual. U kunt het debugtype dat Android Studio gebruikt wijzigen door uw debugconfiguratie te bewerken. Om meer te leren over de verschillende debug-typen, leest u de sectie over het gebruik van andere debug-typen.
Wanneer Android Studio uw app naar uw doelapparaat uitvoert, wordt het Debug-venster geopend met een tabblad of debug-sessieweergave voor elk debug-proces, zoals weergegeven in figuur 4.
Figuur 4. Debuggen van native code met LLDB
- Android Studio schakelt over naar het <uw-module>-tabblad wanneer LLDB-debugger een breekpunt tegenkomt in uw C/C++ code. De vensters Frames, Variabelen en Horloges zijn ook beschikbaar en werken precies zoals ze zouden werken als u Java-code aan het debuggen was. Hoewel het deelvenster Threads niet beschikbaar is in de LLDB-sessieweergave, kunt u toegang krijgen tot uw applicatieprocessen via de vervolgkeuzelijst in het deelvenster Frames. U kunt meer te weten komen over deze deelvensters in de hoofdstukken over het debuggen van vensterframes en het inspecteren van variabelen.
Opmerking: Tijdens het inspecteren van een breekpunt in uw native code, schort het Android systeem de virtuele machine op die de Java bytecode van uw app uitvoert. Dit betekent dat u niet in staat bent om te communiceren met de Java debugger of enige statusinformatie op te halen uit uw Java debugger sessie tijdens het inspecteren van een breekpunt in uw native code.
- Android Studio schakelt over naar het <uw-module>-java-tabblad wanneer de Java-debugger een breekpunt in uw Java-code tegenkomt.
- Tijdens het debuggen met LLDB kunt u de LLDB-terminal in de LLDB-sessieweergave gebruiken om opdrachtregelopties aan LLDB door te geven. Als u bepaalde commando’s wilt dat LLDB uitvoert elke keer dat u begint met het debuggen van uw app, net voor of net na de debugger hecht aan uw app-proces, kunt u deze commando’s toevoegen aan uw debug-configuratie.
Tijdens het debuggen van C/C++ code, kunt u ook speciale soorten breekpunten instellen, genaamd watchpoints, die uw app proces kunnen opschorten wanneer uw app in contact komt met een bepaald blok van het geheugen. Lees voor meer informatie het gedeelte over het toevoegen van onderbrekingspunten.
Onderbrekingspunten bekijken en configureren
Om alle onderbrekingspunten te bekijken en onderbrekingspuntinstellingen te configureren, klikt u op Onderbrekingspunten bekijken aan de linkerkant van het Debug-venster. Het venster Breakpoints verschijnt, zoals getoond in afbeelding 5.
Afbeelding 5. Het venster Onderbrekingspunten geeft een overzicht van alle huidige onderbrekingspunten en bevat gedragsinstellingen voor elk
Met het venster Onderbrekingspunten kunt u elk onderbrekingspunt uit de lijst aan de linkerkant in- of uitschakelen. Als een breekpunt is uitgeschakeld, zal Android Studio uw app niet pauzeren wanneer het dat breekpunt bereikt. Selecteer een onderbrekingspunt in de lijst om de instellingen ervan te configureren. U kunt een onderbrekingspunt configureren om eerst te worden uitgeschakeld en het systeem het te laten inschakelen nadat een ander onderbrekingspunt is geraakt. U kunt ook instellen of een breekpunt moet worden uitgeschakeld nadat het is geraakt. Om een onderbrekingspunt voor een uitzondering in te stellen, selecteert u Uitzondering onderbrekingspunten in de lijst van onderbrekingspunten.
Debug venster frames
In het Debugger venster, laat het Frames deelvenster u het stack frame inspecteren dat het huidige onderbrekingspunt veroorzaakte om geraakt te worden. Dit stelt u in staat om te navigeren en het stack frame te onderzoeken en ook de lijst van threads in uw Android app te inspecteren. Om een thread te selecteren, gebruik de thread selector drop-down en bekijk zijn stack frame. Door te klikken op de elementen in het frame opent u de bron in de editor. U kunt ook de presentatie van de thread aanpassen en het stack frame exporteren, zoals besproken in de Window Frames gids.
Variabelen inspecteren
In het Debugger-venster kunt u met het deelvenster Variabelen variabelen inspecteren wanneer het systeem uw app stopt op een breekpunt en u een frame selecteert uit het deelvenster Frames. In het deelvenster Variabelen kunt u ook ad-hoc-expressies evalueren met behulp van statische methoden en/of variabelen die beschikbaar zijn in het geselecteerde frame.
Het deelvenster Horloges biedt vergelijkbare functionaliteit, behalve dat expressies die aan het deelvenster Horloges zijn toegevoegd, blijven bestaan tussen debuggingssessies. U zou watches moeten toevoegen voor variabelen en velden die u vaak gebruikt of die een toestand bieden die nuttig is voor de huidige debuggingssessie. De deelvensters Variabelen en Horloges verschijnen zoals weergegeven in figuur 5.
Om een variabele of expressie aan de lijst met Horloges toe te voegen, volgt u deze stappen:
- Begin debugging.
- Klik in het deelvenster Watches op Add.
- Typ in het tekstvak dat verschijnt de naam van de variabele of expressie die u in de gaten wilt houden en druk vervolgens op Enter.
Om een item uit de lijst met Favorieten te verwijderen, selecteert u het item en klikt u vervolgens op Verwijderen .
U kunt de volgorde van de elementen in de lijst met Favorieten wijzigen door een item te selecteren en vervolgens op Omhoog of Omlaag .
te klikken Figuur 6. De vensters Variabelen en Horloges in het Debugger-venster
Watchpoints toevoegen
Tijdens het debuggen van C/C++ code kunt u speciale typen breakpoints instellen, watchpoints genaamd, die uw app-proces kunnen opschorten wanneer uw app een bepaald blok geheugen interacteert. Als u bijvoorbeeld twee pointers naar een blok geheugen instelt en er een watchpoint aan toewijst, triggert het gebruik van een van beide pointer om toegang te krijgen tot dat blok geheugen het watchpoint.
In Android Studio kunt u tijdens runtime een watchpoint maken door een specifieke variabele te selecteren, maar LLDB wijst het watchpoint alleen toe aan het blok geheugen dat het systeem aan die variabele toewijst, niet aan de variabele zelf. Dit is anders dan het toevoegen van een variabele aan het deelvenster Horloges, waarmee u de waarde van een variabele kunt observeren, maar niet uw app-proces kunt opschorten wanneer het systeem de waarde in het geheugen leest of wijzigt.
Opmerking: Wanneer uw app-proces een functie verlaat en het systeem zijn lokale variabelen uit het geheugen verwijdert, moet u alle watchpoints die u voor die variabelen hebt gemaakt, opnieuw toewijzen.
Om een watchpoint in te stellen, moet u aan de volgende vereisten voldoen:
- Uw fysieke doelapparaat of emulator maakt gebruik van een x86 of x86_64 CPU. Als uw apparaat een ARM CPU gebruikt, moet u de grens van het adres van uw variabele in het geheugen uitlijnen op 4 bytes voor 32-bits processors, of 8 bytes voor 64-bits processors. U kunt een variabele in uw native code uitlijnen door
__attribute__((aligned(num_bytes)))
op te geven in de variabelenvertraging, zoals hieronder getoond:// For a 64-bit ARM processorint my_counter __attribute__((aligned(8)));
- U hebt al drie of minder watchpoints toegewezen. Android Studio ondersteunt alleen tot vier watchpoints op x86 of x86_64 doelapparaten. Andere apparaten kunnen minder watchpoints ondersteunen.
Opmerking: Bij het debuggen van uw app met 32-bit ARM ABI’s kan het toevoegen van een watchpoint of het met de muis over variabelen in de code gaan om hun waarden te onderzoeken, een crash veroorzaken. Als workaround kunt u debuggen met 64-bit ARM, x86, of x86_64 binaries. Dit probleem zal worden opgelost in een komende Android Studio-release.
Als u aan de bovenstaande vereisten voldoet, kunt u als volgt een watchpoint toevoegen:
- Terwijl uw app op een breakpoint is opgeschort, navigeert u naar het deelvenster Variabelen in uw LLDB-sessieweergave.
-
Klik met de rechtermuisknop op een variabele die het blok geheugen inneemt dat u wilt volgen en selecteer Watchpoint toevoegen. Er verschijnt een dialoogvenster om uw watchpoint te configureren, zoals getoond in figuur 7.
Figuur 7. Een watchpoint toevoegen aan een variabele in het geheugen
- Configureer uw watchpoint met de volgende opties:
- Ingeschakeld: U kunt deze optie deselecteren als u Android Studio wilt vertellen om het watchpoint voorlopig te negeren. Android Studio slaat nog steeds uw watchpoint op zodat u het later in uw debug sessie kunt benaderen.
- Opschorten: Standaard schort het Android-systeem uw app-proces op wanneer het een blok geheugen benadert dat u toewijst aan een watchpoint. U kunt deze optie deselecteren als u dit gedrag niet wilt-dit onthult extra opties die u kunt gebruiken om het gedrag aan te passen wanneer het systeem interageert met uw watchpoint: Log message to console en Remove when hit.
- Toegangstype: Selecteer of uw app uw watchpoint moet triggeren wanneer het probeert te lezen of te schrijven naar het blok geheugen dat het systeem aan de variabele toewijst. Om uw watchpoint te triggeren bij lezen of schrijven, selecteert u Elke.
- Klik op Klaar.
Om al uw watchpoints te bekijken en watchpoint instellingen te configureren, klikt u op View Breakpoints aan de linkerkant van het Debug venster. Het dialoogvenster Breakpoints verschijnt, zoals weergegeven in figuur 8.
Figuur 8. Het dialoogvenster Breakpoints geeft een overzicht van uw huidige watchpoints en bevat gedragsinstellingen voor elk
Nadat u uw watchpoint hebt toegevoegd, klikt u op Resume Program aan de linkerkant van het Debug-venster om het proces van uw app te hervatten. Standaard, als uw app toegang probeert te krijgen tot een blok geheugen waarop u een watchpoint hebt ingesteld, schort het Android-systeem uw app-proces op en verschijnt er een watchpointpictogram naast de regel code die uw app als laatste heeft uitgevoerd, zoals te zien is in figuur 9.
Figuur 9. Android Studio geeft de regel code aan die uw app uitvoert vlak voor het triggeren van een watchpoint
Weergave-indeling voor resourcewaarden bekijken en wijzigen
In de debug-modus kunt u resourcewaarden bekijken en een andere weergave-indeling selecteren voor variabelen in uw Java-code. Met het tabblad Variabelen en een frame geselecteerd, doet u het volgende:
- In de lijst Variabelen klikt u met de rechtermuisknop ergens op een resource-regel om de vervolgkeuzelijst weer te geven.
- In de vervolgkeuzelijst selecteert u Weergeven als en selecteert u de indeling die u wilt gebruiken.
De beschikbare indelingen zijn afhankelijk van het gegevenstype van de geselecteerde resource. U ziet mogelijk een of meer van de volgende opties:
- Klasse: De klasse-definitie weergeven.
- toString: Tekenreeksnotatie weergeven.
- Object: Geef de object (een instantie van een klasse) definitie weer.
- Array: Weergeven in een array-indeling.
- Tijdstempel: Datum en tijd als volgt weergeven: jjjjj-mm-dd hh:mm:ss.
- Auto: Android Studio kiest de beste indeling op basis van het gegevenstype.
- Binair: Geef een binaire waarde weer met behulp van nullen en enen.
- MeasureSpec: De waarde die door de ouder aan het geselecteerde kind wordt doorgegeven. Zie
MeasureSpec
. - Hex: Weergave als een hexadecimale waarde.
- Primitief: Weergave als een numerieke waarde met behulp van een primitief gegevenstype.
- Integer: Weergave van een numerieke waarde van het type
Integer
.
U kunt een aangepaste indeling (renderer van het gegevenstype) maken, als volgt: