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.
Pobieranie logów z Androida
Urządzenie mobilne musi być połączone z komputerem lokalnym podczas wszystkich czynności oznaczonych symbolem adb.
Instalowanie adb
Jeśli nie masz jeszcze skonfigurowanego narzędzia Android Debug Bridge na komputerze lokalnym:
- Zainstaluj „adb” na komputerze.
- Włącz Opcje programisty i debugowanie USB na telefonie Android.
Wtyczka Google Home do Android Studio
Google Home Plugin for Android Studio to przydatne narzędzie do zbierania i analizowania logów, które zostało stworzone specjalnie z myślą o deweloperach Google Home platform. Ta wtyczka zapewnia dostęp do Google Assistant Simulator, Cloud Logging i innych narzędzi, które upraszczają proces tworzenia smart home.
Używaj tego narzędzia w połączeniu z adb, aby dokładniej analizowaćMatter logi urządzenia.
Więcej informacji o narzędziu znajdziesz na stronie Google Home Plugin for Android Studio.
Informacje o wersji
Zalecamy zbieranie wszystkich informacji o wersji związanych z konfiguracją, gdy zdecydujesz się zbierać logi. Jest to wymagane, jeśli chcesz zgłosić problemy Google.
- Uzyskiwanie identyfikatora urządzenia mobilnego:
adb devicesList of devices attached device-id device
- Zapisz tę wartość w zmiennej o nazwie
phoneid:phoneid=device-id - Zapisz różne informacje o urządzeniu w zmiennych:
containerinfo=$(adb -s $phoneid shell dumpsys package com.google.android.gms | grep "versionName" || true); homemoduleinfo=$(adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.home " || true); optionalhomemoduleinfo=$(adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.optional_home " || true); policyhomemoduleinfo=$(adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.policy_home" || true); threadinfo=$(adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.threadnetwork" || true); ghainfo=$(adb -s $phoneid shell dumpsys package com.google.android.apps.chromecast.app | grep versionName || true); enabledfeatures=$((adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "Enabled features" | grep -i "home") || true); androidversion=$(adb -s $phoneid shell getprop ro.build.version.release || true); androidapiversion=$(adb -s $phoneid shell getprop ro.build.version.sdk || 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=$logtimestamp"_versions.txt" echo "Saving version info to $versionfile"
echo "Container version:" >> $versionfile echo $containerinfo >> $versionfile echo "" >> $versionfileecho "Home Module version:" >> $versionfile echo $homemoduleinfo >> $versionfile echo "" >> $versionfileecho "Optional Home Module version:" >> $versionfile echo $optionalhomemoduleinfo >> $versionfile echo "" >> $versionfileecho "Policy Home Module version:" >> $versionfile echo $policyhomemoduleinfo >> $versionfile echo "" >> $versionfileecho "Thread Module version:" >> $versionfile echo $threadinfo >> $versionfile echo "" >> $versionfileecho "GHA version:" >> $versionfile echo $ghainfo >> $versionfile echo "" >> $versionfileecho "Android version: " >> $versionfile echo $androidversion >> $versionfile echo "" >> $versionfileecho "Android API version: " >> $versionfile echo $androidapiversion >> $versionfile echo "" >> $versionfileecho "Found enabled features (blank if missing):" >> $versionfile echo $enabledfeatures >> $versionfile echo "" >> $versionfile - Sprawdź zawartość
_versions.txt:cat _versions.txtW razie potrzeby możesz teraz udostępnić ten plik Google w celu rozwiązania problemu.Rozwiń, aby wyświetlić dane wyjściowe przykładowego pliku
Container version: versionName=23.19.12 (190400-530524295) versionName=22.46.17 (190408-491726958)
Home Module version: com.google.android.gms.home [v230508900]Optional Home Module version:Policy Home Module version: com.google.android.gms.policy_home [230508900] [230508900065.505615668.505615668] [Download:000003be/dl-Home.integ_230508900100400.apk] [download:/Home.integ/230508900100400:Home.integ:230508900100400]Thread Module version: com.google.android.gms.threadnetwork [v231912000]GHA version: versionName=3.2.32.1Android version: 13Android API version: 33Found enabled features (blank if missing):
Zbieranie logów
Aby zebrać logi, zamknij wszystkie aplikacje działające na urządzeniu mobilnym. Następnie:
- Otwórz okno terminala i wyczyść istniejące logi urządzenia:
adb logcat -b all -c - Rozpocznij proces zbierania logów:
adb logcat >> _logs.txt - Uruchom aplikację przykładową i zarejestruj wszystkie działania w interfejsie. Gdy skończysz, zatrzymaj proces
logcatdziałający w terminalu, naciskając Ctrl+C (lub Cmd+C na Macu). - Dzienniki z tej sesji są zapisywane w pliku o nazwie
_logs.txt.
Informacje w tym pliku możesz analizować na różne sposoby, np. wyszukując słowa kluczowe takie jak error, exception lub crash.
Skrypty logu
Przykładowa aplikacja zawiera skrypty, które ułatwiają uzyskiwanie odpowiednich logów i kompilowanie ich w plik tekstowy. Aby zapewnić jak najlepsze debugowanie, te dzienniki należy dołączyć do wszystkich zgłaszanych błędów, aby ułatwić Google analizę ich przyczyn.
Dzienniki te znajdują się w katalogu scripts w drzewie źródłowym aplikacji przykładowej.
Wykonaj te czynności w głównym katalogu projektu:
- Uzyskiwanie identyfikatora urządzenia mobilnego:
adb devices -lList of devices attached device-id device
- Uruchom skrypt
get_logs.sh:./scripts/get_logs.sh device-idCleared previous logs from device. Saving version information to home_api_sample_logs_20240605233243.txt... Saving logs to home_api_sample_logs_20240605233243.txt... (Press CTRL+C to stop the script)
- Odtwórz problem.
- Aby zatrzymać skrypt, naciśnij
CTRL+C.
Skrypt wygeneruje plik dziennika z sygnaturą czasową, który będzie zawierać wszystkie istotne informacje. Dołączaj je do raportów o błędach, które napotkasz.
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, jeśli ma ekran:
- Przesuń palcem z góry ekranu w dół
- Kliknij ikonę Ustawienia .
- Znajdź adres IP urządzenia: na Nest Hub (2nd gen) otwórz Informacje o urządzeniu > Informacje techniczne > Adres IP.
- Z GHA na telefonie:
- Kliknij urządzenie, aby otworzyć stronę z informacjami o nim.
- Kliknij ikonę Ustawienia , aby otworzyć stronę ustawień.
- Znajdź adres IP urządzenia: otwórz Informacje o urządzeniu > Informacje techniczne > Adres IP.
- Na hubie, jeśli ma ekran:
Na komputerze połączonym z tą samą siecią Wi-Fi co urządzenie:
adb connect ip-addressadb logcatAby 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 działaniem początkowym, wykrywanie krawędzi sprawdza, czy działanie początkowe jest aktywowane 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 zmiany).
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ć nieprzewidziane konsekwencje. Zobacz Wpływ usunięcia urządzenia na automatyzacje.
Automatyzacja uruchamia się, gdy nie powinna
Jeśli automatyzacja działa w sytuacjach, w których nie powinna, sprawdź kryteria uruchamiania. 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 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, który będzie zawierał informacje o problemie. Więcej informacji znajdziesz w ValidationIssueType.
Funkcja listy zgłasza wyjątki
Podczas wywoływania funkcji List 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 zainstalowano aplikację
adb. Zobacz Instalowanie adb. Pobierz identyfikator automatyzacji z logów Androida, wywołując:
adb logcat -s GhpNativePrzykł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 | lessUsuń automatyzację za pomocą jej identyfikatora:
structure.deleteAutomation(new object : HasId(id = "1111-2222-3333-44444-55555"))
Interfejs Discovery API rejestruje ostrzeżenie, gdy cecha jest niezarejestrowana
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 rejestracja nie jest wymagana do testowania i korzystania z interfejsów Home API. Nawet jeśli masz zweryfikowanego klienta OAuth z innej integracji, nadal musisz mieć zatwierdzoną Developer Consolerejestrację, aby opublikować aplikację.
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 artykuleSkonfiguruj 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.
W przypadku Google Cloud aplikacji, które wciąż czekają na weryfikację OAuth, użytkownicy nie mogą zakończyć procesu OAuth, dopóki weryfikacja nie zostanie ukończona. Próby przyznania uprawnień zakończą się niepowodzeniem i wyświetli się ten błąd:
Access blocked: <Project Name> has not completed the Google verification process.