Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Rozwiązywanie problemów

Przykładowa aplikacja

Jeśli podczas korzystania z interfejsów Home API napotkasz problemy, możesz zebrać dzienniki w celu dalszego debugowania. Zbieranie logów z urządzenia mobilnego wymaga użycia Android Debug Bridge (adb). Jeśli potrzebujesz pomocy Google, zbierz logi z urządzeń z Androidem i z huba, a potem otwórz zgłoszenie w narzędziu do śledzenia problemów, podając odpowiednie informacje i logi.

Zbieranie logów z Androida

Urządzenie mobilne musi być połączone z komputerem lokalnym podczas wszystkich czynności, w których występuje symbol adb.

Instalowanie adb

Jeśli jeszcze tego nie zrobisz, skonfiguruj Android Debug Bridge na komputerze lokalnym:

Zainstaluj na komputerze narzędzie „adb”.
Włącz opcje programisty i debugowanie USB na telefonie Android.

Pobieranie identyfikatora urządzenia mobilnego

Uzyskiwanie identyfikatora urządzenia mobilnego:

adb devices

List of devices attached
device-id    device

Zapisz tę wartość w zmiennej o nazwie phoneid:
```
phoneid=device-id
```

Informacje o wersji

Zalecamy zbieranie wszystkich informacji o wersjach związanych z konfiguracją, gdy zdecydujesz się zbierać logi. Jest to wymagane, jeśli chcesz zgłosić problemy Google.

Zapisz różne informacje o urządzeniu w zmiennych:

containerinfo=$(adb -s $phoneid shell dumpsys package com.google.android.gms | grep -m 1 "versionName" || true); ghainfo=$(adb -s $phoneid shell dumpsys package com.google.android.apps.chromecast.app | grep -m 1 "versionName" || true); androidversion=$(adb -s $phoneid shell getprop ro.build.version.release || true); androidapiversion=$(adb -s $phoneid shell getprop ro.build.version.sdk || true); chimeradump=$(adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider || true); homemoduleinfo=$(echo "$chimeradump" | grep -w "com.google.android.gms.home" || true); optionalhomemoduleinfo=$(echo "$chimeradump" | grep -w "com.google.android.gms.optional_home" || true); threadinfo=$(echo "$chimeradump" | grep -w "com.google.android.gms.threadnetwork" || true); enabledfeatures=$(echo "$chimeradump" | grep "Enabled features" | grep -i "home" | sort -u || true)

Zapisz wszystkie zmienne w pliku o nazwie _versions.txt:

Rozwiń, aby wyświetlić polecenia zapisywania zmiennych w pliku

Cały blok można skopiować i wkleić do terminala jednocześnie.

versionfile="_versions.txt"
echo "Saving version info to $versionfile"
echo "Container version: $containerinfo" > $versionfile
echo "Home Module version: $homemoduleinfo" >> $versionfile
echo "Optional Home Module version: $optionalhomemoduleinfo" >> $versionfile
echo "Thread Module version: $threadinfo" >> $versionfile
echo "GHA version: $ghainfo" >> $versionfile
echo "Android version: $androidversion" >> $versionfile
echo "Android API version: $androidapiversion" >> $versionfile
echo "Found enabled features: $enabledfeatures" >> $versionfile

Sprawdź zawartość _versions.txt:

cat _versions.txt

Rozwiń, aby wyświetlić dane wyjściowe przykładowego pliku

Container version:     versionName=26.26.34 (190400-945364269)
Home Module version:             com.google.android.gms.home [v262634001]
Optional Home Module version:         com.google.android.gms.optional_home [262634025] ...
Thread Module version:             com.google.android.gms.threadnetwork [v262634001]
GHA version:     versionName=4.22.28.0
Android version: 14
Android API version: 34
Found enabled features:             Enabled features: appsearch_impl, brella_dynamite, dck_management...

W razie potrzeby możesz teraz udostępnić ten plik Google w celu rozwiązania problemu.

Włącz flagi debugowania szczegółowego

Przed zebraniem dzienników urządzenia z Androidem lub uruchomieniem raportu o błędach skonfiguruj rozmiar bufora rejestratora i włącz szczegółowe tagi debugowania dla Google Home i komponentów GMS:

# Clear existing device logs and expand logger buffer size
adb -s $phoneid logcat -b all -c
adb -s $phoneid logcat -G 8M

# Enable GMS Service ID verbose flags
adb -s $phoneid shell setprop log.tag.gms_svc_id:168 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:304 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:305 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:319 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:336 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:360 VERBOSE

# Enable GHP and Matter log tags
adb -s $phoneid shell setprop log.tag.CameraCommissioningPlugin VERBOSE
adb -s $phoneid shell setprop log.tag.HomeSdk VERBOSE
adb -s $phoneid shell setprop log.tag.HomeClient VERBOSE
adb -s $phoneid shell setprop log.tag.InteractionApiChimeraService VERBOSE
adb -s $phoneid shell setprop log.tag.MatterCommissioner VERBOSE
adb -s $phoneid shell setprop log.tag.SampleApp VERBOSE

Zbieranie dzienników Androida za pomocą skryptów

Aby rejestrować dzienniki urządzenia z Androidem na żywo podczas sesji debugowania:

Aby wyczyścić dotychczasowe logi, zwiększyć rozmiar bufora i ustawić tagi szczegółowego rejestrowania, postępuj zgodnie z instrukcjami w sekcji Włączanie szczegółowych flag debugowania.
Zamknij wszystkie aplikacje uruchomione na urządzeniu mobilnym.
Przed rozpoczęciem testu usuń szum z istniejącego bufora logów:
```
adb -s $phoneid logcat -c
```
Rozpocznij proces zbierania logów w oknie terminala:
```
adb -s $phoneid logcat | tee android-logs_$(date +%Y%m%d%H%M%S).txt
```
Nie zamykaj tego okna terminala. Spowoduje to rejestrowanie logów z urządzenia przez cały czas trwania procesu.
Uruchom aplikację i wykonaj wszystkie działania w interfejsie użytkownika, które są potrzebne do odtworzenia problemu.
Gdy to zrobisz, zatrzymaj proces logcat w terminalu, naciskając Ctrl+C (lub Cmd+C na Macu).
Dzienniki z tej sesji są zapisywane w pliku android-logs_YYYYMMDDmmss.txt. Dołączaj do raportów o błędach zarówno android-logs_YYYYMMDDmmss.txt, jak i _versions.txt.

Zbieranie dzienników Androida za pomocą polecenia adb bugreport

Zapisz pełny raport o błędach na Androidzie, gdy chcesz udostępnić szczegółowe informacje diagnostyczne dotyczące problemów na poziomie systemu, zrzutów pamięci po awarii lub debugowania sieci i Bluetootha na niskim poziomie:

Wdrażanie Matter BLE: jeśli zgłaszasz problem z wdrażaniem Matter dotyczący BLE, przed odtworzeniem problemu włącz dziennik snoop Bluetooth HCI w Opcjach programisty (Ustawienia > Opcje programisty > Włącz dziennik snoop Bluetooth HCI).
Konfiguracja przed testem: przed uruchomieniem testu wykonaj czynności opisane w artykule Włączanie flag szczegółowego debugowania, aby włączyć na urządzeniu właściwości szczegółowego debugowania.
Wygeneruj raport o błędzie: po przeprowadzeniu testu i odtworzeniu problemu uruchom to polecenie, aby wygenerować pełne archiwum raportu o błędzie:
```
adb -s $phoneid bugreport ./android-bugreport_$(date +%Y%m%d%H%M%S).zip
```
Zaawansowane informacje do debugowania: wygenerowany plik android-bugreport_YYYYMMDDmmss.zip zawiera kompleksowe dane diagnostyczne na poziomie systemu, w tym pełne zrzuty systemu, statystyki pamięci, diagnostykę baterii i ślady podsystemów niskiego poziomu, co zapewnia bardziej zaawansowane informacje do debugowania.

Dzienniki urządzenia przesyłającego

Za pomocą tej metody możesz wyświetlać dzienniki urządzeń Google Nest Hub. Jest ona obsługiwana w przypadku tych modeli:

Google Home
Google Nest Audio
Google Nest Hub
Google Nest Mini

Aby włączyć centrum Cast do pobierania logów lokalnych:

Skonfiguruj Android Debug Bridge.
Uzyskaj adres IP huba:
- Na hubie z ekranem:
  1. Przesuń palcem z góry ekranu w dół
  2. Kliknij ikonę Ustawienia .
  3. Znajdź adres IP urządzenia: na Nest Hub (2nd gen) otwórz Informacje o urządzeniu > Informacje techniczne > Adres IP.
- Z GHA na telefonie:
  1. Kliknij urządzenie, aby otworzyć stronę z informacjami o nim.
  2. Kliknij ikonę Ustawienia , aby otworzyć stronę ustawień.
  3. Znajdź adres IP urządzenia: otwórz Informacje o urządzeniu > Informacje techniczne > Adres IP.
Na komputerze połączonym z tą samą siecią Wi-Fi co urządzenie:
```
  adb connect ip-address
  adb logcat
```
Aby udostępnić komuś dzienniki, wykonaj operację, która się nie powiodła, i przekieruj dane wyjściowe do pliku tekstowego:
```
  adb logcat -d > platform-logs.txt
```

Automatyzacja

Wykrywanie krawędzi

Automatyzacje w ekosystemie Google Home mają funkcję wykrywania zmian, która sprawdza, czy starter aktywuje się tylko wtedy, gdy nastąpi rzeczywista zmiana stanu, a nie aktualizacja stanu, która po prostu powtarza poprzedni stan urządzenia.

Jeśli na przykład włączenie światła jest starterem, wykrywanie krawędzi sprawdza, czy starter aktywuje się tylko wtedy, gdy urządzenie oświetleniowe przechodzi ze stanu wyłączonego do włączonego, a nie ze stanu włączonego do włączonego (bez zmian).

Automatyzacja nie działa zgodnie z oczekiwaniami

Jeśli po uwzględnieniu wykrywania krawędzi automatyzacja nie działa zgodnie z oczekiwaniami:

Sprawdź każde urządzenie, aby upewnić się, że działa prawidłowo niezależnie od automatyzacji.
Sprawdź wykres automatyzacji, porównując go z językiem DSL automatyzacji, aby wykryć potencjalnie nieprawidłowe założenia.
Obserwuj stan urządzenia w aplikacji Google Home podczas wykonywania automatyzacji.
Sprawdź, czy wszystkie urządzenia, do których odwołuje się automatyzacja, znajdują się w strukturze, w której powinny być. Usunięcie urządzenia, od którego zależy automatyzacja, może mieć niepożądane konsekwencje. Zobacz Wpływ usunięcia urządzenia na automatyzacje.

Automatyzacja uruchamia się, gdy nie powinna

Jeśli automatyzacja uruchamia się w nieodpowiednim momencie, sprawdź kryteria rozpoczęcia. Może być konieczne dodanie dodatkowej logiki, aby mieć pewność, że zmiana stanu zostanie zarejestrowana tylko raz i tylko raz uruchomi automatyzację.

Automatyzacja nie kompiluje się

Upewnij się, że Twoja aplikacja zawiera wszystkie niezbędne importy, w tym każdą klasę odpowiadającą różnym typom węzłów, a także cechy, do których się odwołujesz.

Tworzenie automatyzacji nie przechodzi weryfikacji

Jeśli tworzenie automatyzacji nie przejdzie weryfikacji, pojawi się komunikat z ostrzeżeniem lub błędem zawierający informacje o problemie. Więcej informacji znajdziesz w dokumentacji referencyjnej.ValidationIssueType

Funkcja listy zgłasza wyjątki

Podczas wywoływania funkcji listy interfejsu Automation API moduły obsługi odczytu mogą zgłaszać wyjątki z powodu braku funkcji interfejsu API. Aby temu zapobiec, usuń automatyzację, której to dotyczy.

Aby to zrobić:

Sprawdź, czy aplikacja adb jest zainstalowana. Zobacz Instalowanie adb.

Pobierz identyfikator automatyzacji z logów Androida, wywołując:

adb logcat -s GhpNative

Przykładowe logi:

adb logcat -s GhpNative level:debug | grep -A 10 -B 10 AutomationManagerTrait\.ListResponse

INTERACTION RESPONSE -> SendCommandsResponse:
1 {
1: "automation@global"
3 {
  1: "home.internal.traits.automation.AutomationManagerTrait.ListResponse"
  2:
  5 {
    1: "type.googleapis.com/home.internal.traits.automation.AutomationManagerTrait.ListResponse"
    1 {
        1: "1111-2222-3333-44444-55555" // Automation ID to delete
        2: "structure@2222-3333-4444-5555-6666"
...

Jeśli chcesz usunąć wiele identyfikatorów automatyzacji, możesz użyć pagera terminala, aby kontrolować dane wyjściowe:

adb logcat -s GhpNative level:debug | less

Usuń automatyzację za pomocą jej identyfikatora:

structure.deleteAutomation(new object : HasId(id = "1111-2222-3333-44444-55555"))

Interfejs Discovery API rejestruje ostrzeżenie, gdy cecha zostanie wyrejestrowana

Jeśli interfejs Discovery API rejestruje ostrzeżenie dotyczące Trait not found, oznacza to, że interfejs API próbuje użyć cechy w przypadku kandydatów do odkrywania, ale nie uda mu się to, ponieważ cecha nie została zarejestrowana podczas inicjowania. Na przykład:

09-03 17:45:20.578 10646 10646 W AutomationSdk: trait_id: "home.matter.6006.clusters.fc43" and Exception occurred com.google.home.HomeException: 18: Trait not found: home.matter.6006.clusters.fc43
09-03 17:45:20.578 10646 10646 W AutomationSdk: While converting candidate: # com.google.home.platform.traits.AutomationCandidateNode@76f0b582

Identyfikator cechy to home.matter.6006.clusters.fc43, co odpowiada RelativeHumidityControl. Aby określić nazwę cechy na podstawie identyfikatora, zapoznaj się z indeksem cech.

Z tego przykładu wynika, że RelativeHumidityControl musi zostać zarejestrowany podczas inicjowania aplikacji. Aby dodać cechę do rejestru, zapoznaj się z sekcją Rejestrowanie cech.

OAuth

Jeśli masz już klienta OAuth

Jeśli masz już zweryfikowanego klienta OAuth dla opublikowanej aplikacji, możesz go użyć do testowania interfejsów Home API.

Google Home Developer Console nie jest wymagana do testowania i korzystania z interfejsów Home API. Aby opublikować aplikację, musisz mieć zatwierdzoną Developer Consolerejestrację, nawet jeśli masz zweryfikowanego klienta OAuth z innej integracji.

Pamiętaj o tych kwestiach:

Jeśli używasz istniejącego klienta OAuth, obowiązuje limit 100 użytkowników. Informacje o dodawaniu użytkowników testowych znajdziesz w sekcjiSkonfiguruj ekran zgody OAuth. Niezależnie od weryfikacji OAuth interfejsy Home API mają limit 100 użytkowników, którzy mogą przyznawać uprawnienia Twojej aplikacji. To ograniczenie zostanie zniesione po zakończeniu rejestracji w Developer Console.
Developer Console registration należy przesłać do zatwierdzenia, gdy chcesz ograniczyć przyznawanie uprawnień do typów urządzeń za pomocą OAuth w ramach przygotowań do zaktualizowania aplikacji za pomocą interfejsów Home API.

Ważne: rejestracja w konsoli deweloperskiej Google Home nie jest jeszcze możliwa.

W przypadku Google Cloud aplikacji, które wciąż oczekują na weryfikację OAuth, użytkownicy nie mogą zakończyć procesu OAuth do czasu zakończenia weryfikacji. Próby przyznania uprawnień zakończą się niepowodzeniem z tym błędem:

Access blocked: <Project Name> has not completed the Google verification process.