Ta strona została przetłumaczona przez Cloud Translation API.

Ulepszanie kodu za pomocą sprawdzania lintków

Oprócz testowania kompilacji, aby sprawdzić, czy aplikacja spełnia wymagania funkcjonalne, warto też przepuścić kod przez narzędzie lint, aby upewnić się, że nie ma w nim problemów strukturalnych. Narzędzie lint pomaga znaleźć źle sformatowany kod, który może wpływać na niezawodność i wydajność aplikacji na Androida oraz utrudniać utrzymanie kodu. Zdecydowanie zalecamy poprawienie wszystkich błędów wykrytych przez linter przed opublikowaniem aplikacji.

Jeśli na przykład pliki zasobów XML zawierają nieużywane przestrzenie nazw, zajmują one miejsce i wymagają niepotrzebnego przetwarzania. Inne problemy strukturalne, takie jak używanie przestarzałych elementów lub wywołań interfejsu API, które nie są obsługiwane przez docelowe wersje interfejsu API, mogą powodować nieprawidłowe działanie kodu. Lint może pomóc Ci w rozwiązaniu tych problemów.

Aby poprawić wydajność lintingu, możesz też dodać adnotacje do kodu.

Omówienie

Android Studio udostępnia narzędzie do skanowania kodu o nazwie lint, które może pomóc w identyfikowaniu i poprawianiu problemów z jakością strukturalną kodu bez konieczności uruchamiania aplikacji lub pisania przypadków testowych. Każdy problem wykryty przez narzędzie jest raportowany wraz z opisem i poziomem ważności, aby umożliwić Ci ustawienie priorytetów w przypadku kluczowych ulepszeń, które należy wprowadzić. Możesz też obniżyć poziom ważności problemu, aby pominąć problemy, które nie są istotne dla Twojego projektu, lub zwiększyć poziom ważności, aby wyróżnić konkretne problemy.

Narzędzie lint sprawdza pliki źródłowe projektu Androida pod kątem potencjalnych błędów i możliwości optymalizacji pod kątem poprawności, bezpieczeństwa, wydajności, użyteczności, ułatwień dostępu i międzynarodowości. Podczas kompilowania aplikacji w Android Studio przeprowadzane są inspekcje skonfigurowanego narzędzia lint i IDE. Możesz jednak uruchamiać inspekcje ręcznie lub uruchamiać lint z poziomu wiersza poleceń, jak opisano na tej stronie.

Wbudowane narzędzie lint sprawdza kod podczas korzystania z Androida Studio. Ostrzeżenia i błędy możesz wyświetlić na 2 sposoby:

jako tekst wyskakujący w oknie edytora. Gdy lint znajdzie problem, wyróżni problem żółtym kolorem. W przypadku poważniejszych problemów kod jest podkreślony na czerwono.
W oknie Wyniki kontroli kliknij Kod > Sprawdź kod.

Uwaga: gdy kod jest kompilowany w Android Studio, dodatkowe sprawdzanie kodu IntelliJ jest wykonywane w celu usprawnienia sprawdzania kodu. Upewnij się, że Android Studio jest jak najbardziej aktualne, aby mieć dostęp do najnowszych reguł i sprawdzeń lint.

Rysunek 1 przedstawia, jak narzędzie lint przetwarza pliki źródłowe aplikacji.

Przepływ pracy polegający na skanowaniu kodu za pomocą narzędzia lint. — **Rysunek 1.** Przepływ pracy dotyczący skanowania kodu za pomocą narzędzia lint.

Pliki źródłowe aplikacji: Pliki źródłowe to pliki, które składają się na projekt na Androida, w tym pliki Kotlin, Java i XML, ikony oraz pliki konfiguracyjne ProGuard.
Plik lint.xml: Plik konfiguracji, za pomocą którego możesz określić, jakie kontrole lint chcesz wykluczyć, oraz dostosować poziomy ważności problemów.
Narzędzie do sprawdzania kodu: Narzędzie do skanowania kodu stałego, które możesz uruchomić w projekcie Androida z wiersza poleceń lub w Android Studio. Narzędzie lint sprawdza kod pod kątem problemów strukturalnych, które mogą wpływać na jakość i wydajność aplikacji na Androida.
Wyniki sprawdzania kodu: Wyniki lint możesz wyświetlić w konsoli lub w oknie Wyniki inspekcji w Android Studio. Jeśli uruchomisz lint z poziomu wiersza poleceń, wyniki zostaną zapisane w folderze build/. Więcej informacji znajdziesz w sekcji Ręczne uruchamianie inspekcji.

Uruchamianie lint z poziomu wiersza poleceń

Jeśli używasz Android Studio lub Gradle, uruchom zadanie lint w projekcie, wpisując w katalogu głównym projektu jedno z tych poleceń:

Uwaga: aby korzystać z najnowszych reguł lint, utrzymuj wtyczkę Androida do obsługi Gradle w jak najbardziej aktualnej wersji.

Windows:
```
gradlew lint
```
W systemie Linux lub macOS:
```
./gradlew lint
```

Powinny się wyświetlić dane wyjściowe podobne do tych:

> Task :app:lintDebug
Wrote HTML report to file:<path-to-project>/app/build/reports/lint-results-debug.html

Po zakończeniu sprawdzania narzędzie lint udostępnia ścieżki do wersji raportu lint w formacie XML i HTML. Następnie możesz przejść do raportu HTML i otworzyć go w przeglądarce, jak pokazano na rysunku 2.

Przykładowy raport lint HTML — **Rysunek 2.** Przykładowy raport HTML lint

Jeśli Twój projekt zawiera warianty kompilacji, lint sprawdza tylko wariant domyślny. Jeśli chcesz uruchomić lint na innym wariancie, musisz użyć wielkiej litery w nazwie wariantu i dodać do niej prefiks lint.

./gradlew lintRelease

Uwaga: Lint nie jest uruchamiany automatycznie w ramach kompilacji. Zdecydowanie zalecamy, aby lint był uruchamiany w ramach kompilacji ciągłej integracji, aby podczas kompilowania dotychczasowego kodu źródłowego można było zobaczyć najnowsze kontrole lint.

Więcej informacji o uruchamianiu zadań Gradle z poziomu wiersza poleceń znajdziesz w artykule Tworzenie aplikacji z poziomu wiersza poleceń.

Uruchamianie lint za pomocą samodzielnego narzędzia

Jeśli nie używasz Android Studio ani Gradle, zainstaluj narzędzia wiersza poleceń pakietu Android SDK, aby korzystać z samodzielnego narzędzia lint. Znajdź narzędzie do sprawdzania kodu źródłowego na stronie android_sdk/cmdline-tools/version/bin/lint.

Uwaga: jeśli spróbujesz uruchomić samodzielne narzędzie w projekcie Gradle, pojawi się błąd. Aby uruchomić lint w projekcie Gradle, zawsze używaj gradle lint (w Windows) lub ./gradlew lint (w macOS lub Linux).

Aby uruchomić lint na liście plików w katalogu projektu, użyj tego polecenia:

lint [flags] <project directory>

Aby przeskanować pliki w katalogu myproject i jego podkatalogach, możesz na przykład wydać to polecenie: Identyfikator problemu MissingPrefixmówi, że lint ma skanować tylko atrybuty XML, w których brakuje prefiksu przestrzeni nazw Androida.

lint --check MissingPrefix myproject

Aby wyświetlić pełną listę obsługiwanych przez narzędzie flag i argumentów wiersza poleceń, uruchom to polecenie:

lint --help

Ten przykład pokazuje dane wyjściowe konsoli po uruchomieniu polecenia lint w przypadku projektu o nazwie Earthquake:

$ lint Earthquake

Scanning Earthquake: ...............................................................................................................................
Scanning Earthquake (Phase 2): .......
AndroidManifest.xml:23: Warning: <uses-sdk> tag appears after <application> tag [ManifestOrder]
  <uses-sdk android:minSdkVersion="7" />
  ^
AndroidManifest.xml:23: Warning: <uses-sdk> tag should specify a target API level (the highest verified version; when running on later versions, compatibility behaviors may be enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes]
  <uses-sdk android:minSdkVersion="7" />
  ^
res/layout/preferences.xml: Warning: The resource R.layout.preferences appears to be unused [UnusedResources]
res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 4 warnings

Przykładowy wynik zawiera 4 ostrzeżenia i brak błędów.

2 ostrzeżenia dotyczące pliku AndroidManifest.xml projektu:

ManifestOrder
UsesMinSdkAttributes

Ostrzeżenie dotyczy pliku układu Preferences.xml: UnusedResources.

Jedno ostrzeżenie dotyczy katalogu res: IconMissingDensityFolder.

Konfigurowanie linta w celu pomijania ostrzeżeń

Domyślnie, gdy uruchamiasz skanowanie lint, narzędzie sprawdza wszystkie problemy obsługiwane przez lint. Możesz też ograniczyć problemy, które ma sprawdzać lint, oraz przypisać problemom poziomy ważności. Możesz na przykład wyłączyć sprawdzanie lint w przypadku określonych problemów, które nie są istotne dla Twojego projektu, oraz skonfigurować lint tak, aby zgłaszanie problemów niekrytycznych odbywało się na niższym poziomie ważności.

Poziomy ważności:

enable
disable lub ignore
informational
warning
error
fatal

Możesz skonfigurować sprawdzanie błędów na różnych poziomach:

Globalnie (cały projekt)
Moduł projektu
Moduł produkcji
Moduł testowy
Otwórz pliki
Hierarchia klas
Zakresy systemu kontroli wersji (VCS)

Konfigurowanie pliku lint

Preferencje sprawdzania błędów w plikach typu lint możesz określić w pliku lint.xml. Jeśli tworzysz ten plik ręcznie, umieść go w katalogu głównym projektu Androida.

Plik lint.xml składa się z otaczającego tagu nadrzędnego <lint>, który zawiera co najmniej 1 element podrzędny <issue>. Lint definiuje unikalną wartość atrybutu id dla każdego elementu <issue>:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- list of issues to configure -->
</lint>

Aby zmienić poziom ważności problemu lub wyłączyć sprawdzanie błędów w języku lint, ustaw atrybut ważności w tagu <issue>.

Wskazówka: aby wyświetlić pełną listę problemów obsługiwanych przez lint i odpowiadające im identyfikatory problemów, uruchom polecenie lint --list.

Przykładowy plik lint.xml

Ten przykład pokazuje zawartość pliku lint.xml:

<?xml version="1.0" encoding="UTF-8"?>
<lint>
    <!-- Disable the IconMissingDensityFolder check in this project -->
    <issue id="IconMissingDensityFolder" severity="ignore" />

    <!-- Ignore the ObsoleteLayoutParam issue in the specified files -->
    <issue id="ObsoleteLayoutParam">
        <ignore path="res/layout/activation.xml" />
        <ignore path="res/layout-xlarge/activation.xml" />
    </issue>

    <!-- Ignore the UselessLeaf issue in the specified file -->
    <issue id="UselessLeaf">
        <ignore path="res/layout/main.xml" />
    </issue>

    <!-- Change the severity of hardcoded strings to "error" -->
    <issue id="HardcodedText" severity="error" />
</lint>

Ten przykład pokazuje, jak zgłaszane są różne typy problemów. Sprawdzanie IconMissingDensityFolder jest całkowicie wyłączone, a sprawdzanie ObsoleteLayoutParam jest wyłączone tylko w plikach określonych w załączonych deklaracjach <ignore ... />.

Konfigurowanie sprawdzania lint w przypadku plików źródłowych Kotlina, Javy i XML

W oknie Ustawienia możesz wyłączyć sprawdzanie lint w przypadku plików źródłowych Kotlin, Java i XML:

Wybierz Plik > Ustawienia (w Windows) lub Android Studio > Preferencje (w macOS lub Linuxie).
Kliknij Edytor > Inspekcje.
Aby wyłączyć tę opcję, odznacz odpowiedni plik źródłowy.

Możesz je ustawić dla IDE lub dla poszczególnych projektów, wybierając odpowiedni profil.

Konfigurowanie sprawdzania błędów lint w języku Java lub Kotlin

Aby wyłączyć sprawdzanie linta w przypadku konkretnej klasy lub metody w projekcie Androida, dodaj do tego kodu adnotację @SuppressLint.

Z tego przykładu dowiesz się, jak wyłączyć sprawdzanie błędów w metodzie onCreate w przypadku problemu NewApi. Narzędzie lint nadal sprawdza, czy w innych metodach tej klasy występuje problemNewApi.

Kotlin

@SuppressLint("NewApi")
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main)

Java

@SuppressLint("NewApi")
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

To samo można zrobić w przypadku dowolnego komponentu. Ten fragment kodu pokazuje, jak wyłączyć sprawdzanie NewApi w przypadku dowolnej składowej.

Kotlin

  @SuppressLint("NewApi")
  @Composable
  fun MyComposable{
    ...
  }

Z tego przykładu dowiesz się, jak wyłączyć sprawdzanie lint w przypadku problemu ParserError w klasie FeedProvider:

Kotlin

@SuppressLint("ParserError")
class FeedProvider : ContentProvider() {

Java

@SuppressLint("ParserError")
public class FeedProvider extends ContentProvider {

Aby pominąć sprawdzanie wszystkich problemów z lint w pliku, użyj słowa kluczowego all:

Kotlin

@SuppressLint("all")

Java

@SuppressLint("all")

Możesz użyć tej samej adnotacji, aby pominąć kontrole lint w przypadku dowolnej funkcji kompozytowanej.

Konfigurowanie sprawdzania błędów w kodzie XML

Aby wyłączyć sprawdzanie błędów w przypadku określonych sekcji plików XML, użyj atrybutu tools:ignore. W pliku lint.xml wpisz tę wartość przestrzeni nazw, aby narzędzie lint rozpoznało atrybut:

namespace xmlns:tools="http://schemas.android.com/tools"

Z przykładu poniżej dowiesz się, jak wyłączyć sprawdzanie lint dla problemu UnusedResources w elemencie <LinearLayout> w pliku XML z poziomu układu. Atrybut ignore jest dziedziczony przez elementy podrzędne elementu nadrzędnego, w którym jest zadeklarowany. W tym przykładzie sprawdzanie błędów jest też wyłączone w przypadku elementu podrzędnego <TextView>:

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    tools:ignore="UnusedResources" >

    <TextView
        android:text="@string/auto_update_prompt" />
</LinearLayout>

Aby wyłączyć więcej niż 1 problem, podaj listę problemów do wyłączenia w ciągu rozdzielonym przecinkami. Przykład:

tools:ignore="NewApi,StringFormatInvalid"

Aby pominąć sprawdzanie wszystkich problemów z lintem w elemencie XML, użyj słowa kluczowego all:

tools:ignore="all"

Konfigurowanie opcji lint za pomocą Gradle

Wtyczka Androida do obsługi Gradle umożliwia konfigurowanie niektórych opcji lint, na przykład sprawdzania do wykonania lub zignorowania, za pomocą bloku lint{} w pliku build.gradle na poziomie modułu.

Ten fragment kodu pokazuje niektóre właściwości, które możesz skonfigurować:

Kotlin

android {
    ...
    lint {
        // Turns off checks for the issue IDs you specify.
        disable += "TypographyFractions" + "TypographyQuotes"
        // Turns on checks for the issue IDs you specify. These checks are in
        // addition to the default lint checks.
        enable += "RtlHardcoded" + "RtlCompat" + "RtlEnabled"
        // To enable checks for only a subset of issue IDs and ignore all others,
        // list the issue IDs with the 'check' property instead. This property overrides
        // any issue IDs you enable or disable using the properties above.
        checkOnly += "NewApi" + "InlinedApi"
        // If set to true, turns off analysis progress reporting by lint.
        quiet = true
        // If set to true (default), stops the build if errors are found.
        abortOnError = false
        // If set to true, lint only reports errors.
        ignoreWarnings = true
        // If set to true, lint also checks all dependencies as part of its analysis.
        // Recommended for projects consisting of an app with library dependencies.
        checkDependencies = true
    }
}
...

Groovy

android {
    ...
    lint {
        // Turns off checks for the issue IDs you specify.
        disable 'TypographyFractions','TypographyQuotes'
        // Turns on checks for the issue IDs you specify. These checks are in
        // addition to the default lint checks.
        enable 'RtlHardcoded','RtlCompat', 'RtlEnabled'
        // To enable checks for only a subset of issue IDs and ignore all others,
        // list the issue IDs with the 'check' property instead. This property overrides
        // any issue IDs you enable or disable using the properties above.
        checkOnly 'NewApi', 'InlinedApi'
        // If set to true, turns off analysis progress reporting by lint.
        quiet true
        // If set to true (default), stops the build if errors are found.
        abortOnError false
        // If set to true, lint only reports errors.
        ignoreWarnings true
        // If set to true, lint also checks all dependencies as part of its analysis.
        // Recommended for projects consisting of an app with library dependencies.
        checkDependencies true
    }
}
...

Wszystkie metody lint, które zastępują dany poziom wagi problemu, przestrzegają kolejności konfiguracji. Na przykład ustawienie problemu jako krytycznego w finalizeDsl() zastępuje wyłączenie w głównym pliku DSL.

Tworzenie wartości odniesienia dla ostrzeżeń

Możesz wykonać zrzut ekranu bieżącego zestawu ostrzeżeń w projekcie, a następnie użyć go jako punktu odniesienia do przyszłych inspekcji, aby zgłaszane były tylko nowe problemy. Zrzut bazowy umożliwia użycie lint do anulowania kompilacji bez konieczności wcześniejszego rozwiązywania wszystkich istniejących problemów.

Aby utworzyć zrzut domyślny, zmodyfikuj plik build.gradle projektu w ten sposób:

Kotlin

android {
    lint {
        baseline = file("lint-baseline.xml")
    }
}

Groovy

android {
    lintOptions {
        baseline file("lint-baseline.xml")
    }
}

Gdy po raz pierwszy dodajesz ten wiersz, tworzony jest plik lint-baseline.xml, który służy do określenia wartości wyjściowej. Od tego momentu narzędzia tylko odczytują plik, aby określić wartość bazową. Jeśli chcesz utworzyć nowy punkt odniesienia, ręcznie usuń plik i ponownie uruchom lint, aby go utworzyć.

Następnie uruchom lint w IDE, wybierając Kod > Sprawdź kod, lub z poziomu wiersza poleceń w ten sposób: Wyjściem jest wydrukowanie lokalizacji pliku lint-baseline.xml. Lokalizacja pliku w przypadku Twojej konfiguracji może być inna niż widoczna tutaj:

$ ./gradlew lintDebug -Dlint.baselines.continue=true
...
Wrote XML report to file:///app/lint-baseline.xml
Created baseline file /app/lint-baseline.xml

Uruchomienie lint powoduje zapisanie wszystkich bieżących problemów w pliku lint-baseline.xml. Zestaw bieżących problemów jest nazywany wartością bazową. Jeśli chcesz udostępnić plik lint-baseline.xml innym osobom, możesz go dodać do kontroli wersji.

Dostosowywanie wartości bazowej

Jeśli chcesz dodać do bazy tylko określone typy problemów, określ, które problemy mają zostać dodane, edytując plik build.gradle projektu w ten sposób:

Kotlin

android {
    lint {
        checkOnly += "NewApi" + "HandlerLeak"
        baseline = file("lint-baseline.xml")
    }
}

Groovy

android {
    lintOptions {
        checkOnly 'NewApi', 'HandlerLeak'
        baseline file("lint-baseline.xml")
    }
}

Jeśli po utworzeniu bazy porównawczej dodasz do bazy kodu nowe ostrzeżenia, lint wyświetli tylko nowe błędy.

Ostrzeżenie o wartościach domyślnych

Gdy obowiązuje wartość domyślna, otrzymasz ostrzeżenie informacyjne, że co najmniej 1 problem został odfiltrowany, ponieważ jest wymieniony w wartości domyślnej. To ostrzeżenie przypomina, że masz skonfigurowaną wartość bazową i że w pewnym momencie musisz rozwiązać wszystkie problemy.

To ostrzeżenie informacyjne śledzi też problemy, które nie są już zgłaszane. Te informacje pozwalają Ci sprawdzić, czy problemy zostały rzeczywiście rozwiązane. Możesz też ponownie utworzyć bazę odniesienia, aby zapobiec ponownemu wystąpieniu niezauważonego błędu.

Uwaga: wartości domyślne są włączone podczas wykonywania inspekcji w trybie zbiorczym w IDE, ale są ignorowane w przypadku kontroli w edytorze, które są wykonywane w tle podczas edycji pliku. Dzieje się tak, ponieważ wartości domyślne są przeznaczone do sytuacji, gdy baza kodu ma dużą liczbę ostrzeżeń, ale chcesz rozwiązać problemy lokalnie podczas wprowadzania zmian w kodzie.

Ręczne przeprowadzanie inspekcji

Aby ręcznie uruchomić skonfigurowane narzędzie lint i inne inspekcje IDE, kliknij Kod > Sprawdzanie kodu. Wyniki kontroli pojawią się w oknie Wyniki kontroli.

Ustawianie zakresu i profilu inspekcji

Wybierz pliki, które chcesz analizować (zakres inspekcji), oraz inspekcje, które chcesz przeprowadzić (profil inspekcji) w ten sposób:

W widoku Android otwórz projekt i wybierz projekt, folder lub plik, który chcesz przeanalizować.
Na pasku menu kliknij Kod > Sprawdź kod.
W oknie Określ zakres sprawdzania sprawdź ustawienia.

Rysunek 3. Sprawdź ustawienia zakresu inspekcji.

Opcje widoczne w oknie Określ zakres inspekcji różnią się w zależności od tego, czy wybrano projekt, folder czy plik:
- Gdy wybierzesz jeden projekt, plik lub katalog, w oknie Określ zakres inspekcji wyświetli się ścieżka do wybranego projektu, pliku lub katalogu.
- Gdy wybierzesz więcej niż jeden projekt, plik lub katalog, w oknie Określ zakres inspekcji będzie zaznaczony przycisk radiowy Wybrane pliki.
Aby zmienić element do sprawdzenia, wybierz jeden z pozostałych przycisków opcji. Aby dowiedzieć się więcej o wszystkich polach w oknie Określanie zakresu kontroli, zapoznaj się z artykułem Okno Określanie zakresu kontroli.
W sekcji Profil inspekcji wybierz profil, którego chcesz użyć.
Aby rozpocząć inspekcję, kliknij OK.

Rysunek 4 przedstawia wyniki kontroli lint i innych kontroli IDE z uruchomienia Sprawdź kod:

Rysunek 4. Wyniki kontroli. Wybierz problem, aby zobaczyć jego rozwiązanie.
W panelu Wyniki kontroli wyświetl wyniki kontroli, rozwijając i wybierając kategorie, typy lub problemy związane z błędami.

Na panelu Raport z sprawdzenia wyświetlany jest raport z sprawdzenia dotyczący kategorii błędów, typu lub problemu wybranego na panelu Wyniki sprawdzenia. Zawiera on nazwę i lokalizację błędu. W stosownych przypadkach raport z przeskanowania zawiera inne informacje, takie jak podsumowanie problemu, które ułatwia jego rozwiązanie.
W widoku drzewa panelu Wyniki inspekcji kliknij prawym przyciskiem myszy kategorię, typ lub problem, aby wyświetlić menu kontekstowe.

W zależności od kontekstu możesz:
- Przejdź do źródła.
- Wykluczanie i uwzględnianie wybranych elementów.
- Problemy z tłumieniem.
- Zmień ustawienia.
- Zarządzaj alertami dotyczącymi kontroli.
- Przeprowadź ponownie inspekcję.

Opisów przycisków na pasku narzędzi, elementów menu kontekstowego i pól raportu inspekcji szukaj w oknie narzędzia Wyniki inspekcji.

Używanie zakresu niestandardowego

Użyj jednego z zakresów niestandardowych dostępnych w Android Studio w ten sposób:

W oknie Określ zakres inspekcji kliknij Zakres niestandardowy.
Kliknij listę Zakres niestandardowy, aby wyświetlić opcje:

Rysunek 5. Wybierz zakres niestandardowy, którego chcesz użyć.
- Wszystkie miejsca:wszystkie pliki.
- Pliki projektu: wszystkie pliki w bieżącym projekcie.
- Pliki źródłowe projektu: tylko pliki źródłowe w bieżącym projekcie.
- Pliki produkcyjne projektu: tylko pliki produkcyjne w bieżącym projekcie.
- Pliki testowe projektu:tylko pliki testowe z bieżącego projektu.
- Scratches and Consoles:tylko te pliki i konsole, które są otwarte w bieżącym projekcie.
- Ostatnio wyświetlane pliki:tylko ostatnio wyświetlane pliki w bieżącym projekcie.
- Bieżący plik: tylko bieżący plik w bieżącym projekcie. Pojawia się, gdy wybierzesz plik lub folder.
- Wybrany katalog: tylko bieżący folder w bieżącym projekcie. Pojawia się, gdy masz wybrany folder.
- Hierarchia klas: po wybraniu tej opcji i kliknięciu OK pojawi się okno ze wszystkimi klasami w bieżącym projekcie. W oknie użyj pola Szukaj według nazwy, aby filtrować i wybierać klasy do sprawdzenia. Jeśli nie przefiltrujesz listy zajęć, inspekcja kodu sprawdzi wszystkie zajęcia.

Jeśli w przypadku projektu masz skonfigurowany system kontroli wersji, możesz też ograniczyć wyszukiwanie do plików, które zostały zmodyfikowane.

Kliknij OK.

Tworzenie zakresu niestandardowego

Jeśli chcesz sprawdzić wybrane pliki i katalogi, które nie są objęte żadnym z dostępnych zakresów niestandardowych, możesz utworzyć zakres niestandardowy:

W oknie Określ zakres inspekcji kliknij Zakres niestandardowy.
Kliknij 3 kropki obok listy Zakres niestandardowy.

Rysunek 6. Okno Określ zakres inspekcji

Pojawi się okno Zakresy.

Rysunek 7. Utwórz zakres niestandardowy.
Aby zdefiniować nowy zakres, w lewym górnym rogu okna kliknij przycisk .
Na wyświetlonej liście Dodaj zakres wybierz Lokalny.
Zarówno zakres lokalny, jak i wspólny są używane w projekcie w funkcji Sprawdź kod. Zakres wspólny można też używać z innymi funkcjami projektu, które mają pole zakresu. Gdy na przykład klikniesz Edytuj ustawienia , aby zmienić ustawienia Znajdź użycia, w wyświetlonym oknie dialogowym pojawi się pole Zakres, w którym możesz wybrać wspólny zakres.

Rysunek 8. W oknie Znajdź użycia wybierz zakres udostępniania.
Nadaj zakresowi nazwę i kliknij OK.
Prawa część okna Zakresy wypełnia się opcjami, które umożliwiają zdefiniowanie zakresu niestandardowego.
Z listy wybierz Projekt.
Pojawi się lista dostępnych projektów.

Uwaga: możesz utworzyć niestandardowy zakres dla projektów lub pakietów. Procedura jest taka sama.
Rozwiń foldery projektu, wybierz, co chcesz dodać do zakresu niestandardowego, i określ, czy ma być uwzględnione, czy wykluczone.

Rysunek 9. Zdefiniuj zakres niestandardowy.
- Uwzględnij: ten folder i jego pliki, ale nie uwzględniaj żadnych jego podfolderów.
- Uwzględnij rekursywnie: uwzględnia ten folder i jego pliki, a także jego podfoldery i pliki w nich.
- Wyklucz: wyklucz ten folder i jego pliki, ale nie wykluczaj żadnych jego podfolderów.
- Wyklucz rekursywnie: wyklucz ten folder i jego pliki, a także jego podfoldery i pliki w nich.
Rysunek 10 pokazuje, że uwzględniono folder main oraz że foldery java i res są uwzględniane rekurencyjnie. Niebieski kolor wskazuje częściowo uwzględniony folder, a zielony – rekurencyjnie uwzględnione foldery i pliki.

Rysunek 10. Przykładowy wzór dla zakresu niestandardowego.
- Jeśli wybierzesz folder java i klikniesz Wyklucz rekursywnie, zielone podświetlenie zniknie z folderu java oraz wszystkich folderów i plików w jego obrębie.
- Jeśli wybierzesz wyróżniony na zielono plik MainActivity.kt i klikniesz Wyklucz, plik MainActivity.kt nie będzie już wyróżniony na zielono, ale wszystko inne w folderze java pozostanie zielone.
Kliknij OK. Zakres niestandardowy pojawi się u dołu listy.

Sprawdzanie i edytowanie profili kontroli

Android Studio zawiera kilka profili lint i innych profili inspekcji, które są aktualizowane wraz z aktualizacjami Androida. Możesz używać tych profili w niezmienionej postaci lub edytować ich nazwy, opisy, wagi i zakresy. Możesz też aktywować i dezaktywować całe grupy profili lub poszczególne profile w grupie.

Aby otworzyć ustawienia Inspekcji:

Wybierz Plik > Ustawienia. (w Windows) lub Android Studio > Preferencje (w macOS lub Linux).
Kliknij Edytor > Inspekcje.
Panel Inspekcje zawiera listę obsługiwanych inspekcji i ich opisów.

Rysunek 11. Obsługiwane inspekcje i ich opisy.
Wybierz listę Profil, aby przełączać się między inspekcjami Domyślna (Android Studio) i Domyślna w projekcie (aktywnego projektu).

Więcej informacji znajdziesz na stronie Zarządzanie profilami w IntelliJ.
Na liście Inspekcje w panelu po lewej stronie wybierz kategorię profilu najwyższego poziomu lub rozwiń grupę i wybierz konkretny profil.

Po wybraniu kategorii profilu możesz edytować wszystkie inspekcje w tej kategorii jako jedną inspekcję.
Wybierz listę Pokaż działania schematu , aby kopiować, zmieniać nazwy, dodawać opisy, eksportować i importować inspekcje.
Gdy skończysz, kliknij OK.