Samodzielne i niesamodzielne aplikacje na Wear OS

Zalecamy, aby aplikacje na Wear OS działały niezależnie od telefonu, dzięki czemu użytkownicy mogą wykonywać zadania na zegarku bez dostępu do telefonu z Androidem lub iOS. Jeśli aplikacja na zegarek wymaga interakcji z telefonem, musisz oznaczyć aplikację na Wear OS jako niesamodzielną i podjąć działania, aby użytkownik miał dostęp do aplikacji na telefon.

Planowanie aplikacji

Możesz użyć pakietu Android App Bundle , aby automatycznie generować zoptymalizowane pakiety Android Package Kit (APK) dla każdej konfiguracji urządzenia użytkownika w ramach tej samej strony aplikacji. Dzięki temu użytkownicy mogą pobierać tylko kod i zasoby potrzebne do uruchomienia Twojej aplikacji.

Informacje o konfigurowaniu aplikacji do rozpowszechniania w Sklepie Google Play znajdziesz w artykułach Pakowanie i rozpowszechnianie aplikacji na Wear OS oraz Wprowadzenie do pakietów Android App Bundle.

W przypadku nowych aplikacji docelowy poziom interfejsu API musi wynosić co najmniej 34. Więcej informacji znajdziesz w artykule Wymagania Google Play dotyczące docelowego poziomu interfejsu API. Kierowanie na najnowszy dostępny poziom interfejsu API pomaga zapewnić, że aplikacja będzie dobrze działać w obecnych wersjach platformy.

Informacje o żądaniach sieciowych i dostępie do sieci o dużej przepustowości znajdziesz w artykule Dostęp do sieci i synchronizacja na Wear OS.

Określanie aplikacji jako aplikacji na Wear OS

W pliku manifestu Androida aplikacji musisz zdefiniować tag <uses-feature>. Aby wskazać, że jest to aplikacja na zegarek, dodaj wpis taki jak ten: 

<uses-feature android:name="android.hardware.type.watch" />

Określanie aplikacji jako samodzielnej lub niesamodzielnej

Aplikacja na zegarek jest uważana za samodzielną lub niesamodzielną:

  • Samodzielna: całkowicie niezależna aplikacja, która do działania podstawowych funkcji nie wymaga aplikacji na telefon. Chociaż akceptowalne są prośby o otwarcie aplikacji na telefonie, aplikacja musi zapewniać użytkownikom alternatywne sposoby wykonywania funkcji aplikacji – np. krótki link lub kod QR – bez konieczności korzystania z telefonu połączonego w tetheringu.
  • Niesamodzielna: zależna aplikacja, która do działania podstawowych funkcji wymaga aplikacji na telefon lub inne urządzenie. Ta opcja jest najlepsza w przypadku aplikacji, które nie mogą łatwo zapewnić alternatywnego sposobu – np. kodu QR lub krótkiego linku – na wykonanie podstawowej funkcji aplikacji, takiej jak uwierzytelnianie.

Uwaga: nawet w przypadku aplikacji niesamodzielnych użytkownicy mogą zainstalować aplikację na Wear OS przed aplikacją mobilną. Jeśli więc aplikacja na Wear OS wykryje, że na pobliskim urządzeniu przenośnym nie ma wymaganej aplikacji towarzyszącej, poproś użytkownika o jej zainstalowanie.

Podczas wyświetlania aplikacji Google sprawdza, czy jej stan samodzielności jest prawidłowy. Ta wartość wpływa na widoczność aplikacji w Sklepie Play na urządzeniach niepołączonych w tetheringu, takich jak urządzenia z Wear OS, które nie są sparowane z urządzeniami przenośnymi. Aplikacje niesamodzielne – a także aplikacje, które deweloperzy nieprawidłowo oznaczyli jako "samodzielne" – nie są dostępne dla użytkowników na tych urządzeniach niepołączonych w tetheringu.

Aby zadeklarować, czy aplikacja jest samodzielna czy niesamodzielna, w pliku manifestu Androida aplikacji na Wear OS ustaw wartość elementu meta-data com.google.android.wearable.standalone.

Jeśli aplikacja na zegarek jest całkowicie niezależną, samodzielną aplikacją, wskaż to w Sklepie Google Play, ustawiając wartość com.google.android.wearable.standalone na true: 

<meta-data
    android:name="com.google.android.wearable.standalone"
    android:value="true" />

Jeśli aplikacja na zegarek jest niesamodzielna i do działania podstawowych funkcji wymaga innej aplikacji, ustaw wartość com.google.android.wearable.standalone na false. Oznacza to, że aplikacja na zegarek wymaga innego urządzenia, ale nie wpływa na reklamę aplikacji w Sklepie Google Play.

Uwaga: nawet jeśli wartość com.google.android.wearable.standalone to false, aplikację na zegarek można zainstalować przed aplikacją na telefon. Jeśli więc aplikacja na zegarek wykryje, że na powiązanym telefonie nie ma wymaganej aplikacji na telefon, poproś użytkownika o jej zainstalowanie.

Wspólny kod i przechowywanie danych

Kod można udostępniać między aplikacją na Wear OS a aplikacją na telefon. Na przykład wspólny kod do obsługi sieci może znajdować się w bibliotece udostępnionej.

Opcjonalnie kod który jest specyficzny dla danego formatu, może znajdować się w osobnym module.

Do lokalnego przechowywania danych możesz używać standardowych interfejsów API Androida, tak jak na telefonie. Możesz używać DataStore do przechowywania par klucz-wartość i obiektów typowanych lub biblioteki trwałości Room.

Wykrywanie aplikacji na innym urządzeniu

Aplikacja na zegarek i odpowiadająca jej aplikacja na telefon mogą wykrywać, czy druga aplikacja jest dostępna.

Aplikacje na telefon i zegarek mogą używać interfejsu CapabilityClient do informowania o swojej obecności na sparowanym urządzeniu. Mogą to robić statycznie lub dynamicznie.

Gdy aplikacja znajduje się w węźle w sieci Wear OS użytkownika, np. na telefonie, sparowanym zegarku lub w chmurze, CapabilityClient umożliwia innym aplikacjom jej wykrycie. Więcej informacji znajdziesz w artykule Informowanie o możliwościach.

Jeśli jedna z Twoich aplikacji nie może wykryć drugiej, możesz poprosić użytkownika o otwarcie strony aplikacji w Sklepie Play na urządzeniu, którego dotyczy problem. Jest to rozwiązanie dla aplikacji na zegarek, które do prawidłowego działania wymagają obecności powiązanego telefonu.

Musisz sprawdzić, czy Sklep Play jest dostępny na urządzeniu, ponieważ nie wszystkie telefony – np. iPhone'y – obsługują Sklep Play.

W sekcjach poniżej opisujemy sprawdzone metody w 2 scenariuszach:

  • Samodzielna aplikacja na zegarek wymaga aplikacji na telefon.
  • Aplikacja na telefon wymaga samodzielnej aplikacji na zegarek.

Możesz też zapoznać się z przykładem Datalayer helpers, który pokazuje, jak używać bibliotek Datalayer helpers, które są częścią Horologist. Te biblioteki pomocnicze umożliwiają monitorowanie połączenia między urządzeniem przenośnym urządzeniem z Wear OS. Więcej informacji o klasach opisanych w sekcji poniżej znajdziesz w dokumentacji interfejsu Wear OS API. Dokumentacja ta zawiera też informacje o PhoneTypeHelper klasie, która zawiera metodę getPhoneDeviceType(), umożliwiającą aplikacji na Wear OS sprawdzenie, czy powiązany telefon jest urządzeniem z Androidem czy iOS.

Określanie nazw możliwości do wykrywania aplikacji

W przypadku aplikacji odpowiadającej każdemu typowi urządzenia – zegarkowi lub telefonowi – określ unikalny ciąg znaków jako nazwę możliwości w pliku res/values/wear.xml.

Na przykład w module mobilnym plik wear.xml może zawierać te informacje: 

<resources xmlns:tools="http://schemas.android.com/tools"
    tools:keep="@array/android_wear_capabilities">
    <string-array name="android_wear_capabilities">
        <item>verify_remote_example_phone_app</item>
    </string-array>
</resources>

W module Wear OS plik wear.xml zawiera inną wartość nazwy możliwości, np. taką: 

<resources xmlns:tools="http://schemas.android.com/tools"
    tools:keep="@array/android_wear_capabilities">
    <string-array name="android_wear_capabilities">
        <item>verify_remote_example_wear_app</item>
    </string-array>
</resources>

Więcej informacji znajdziesz w artykule Informowanie o możliwościach.

Wykrywanie aplikacji i otwieranie adresu URL z zegarka

Aplikacja na zegarek może wykryć, czy na powiązanym telefonie użytkownika jest zainstalowana Twoja aplikacja na telefon. Aby to zrobić:

  1. Użyj interfejsu CapabilityClient aby sprawdzić, czy aplikacja na telefon jest zainstalowana na sparowanym telefonie. Więcej informacji znajdziesz w przykładzie Datalayer helpers w GitHubie.
  2. Jeśli aplikacja na telefon nie jest zainstalowana na telefonie, użyj metody PhoneDeviceType.getPhoneDeviceType(), aby sprawdzić typ telefonu. Szczegóły znajdziesz w sekcji poniżej.
  3. Jeśli PhoneDeviceType.DEVICE_TYPE_ANDROID zostanie zwrócona, oznacza to, że telefon jest urządzeniem z Androidem. Wywołaj RemoteActivityHelper.startRemoteActivity() na urządzeniu z Wear OS, aby otworzyć Sklep Play na telefonie. Użyj identyfikatora URI rynku dla aplikacji na telefon który może się różnić od identyfikatora URI aplikacji na Wear. Na przykład użyj identyfikatora URI rynku takiego jak: market://details?id=com.example.android.wearable.wear.finddevices.

  4. Jeśli PhoneDeviceType.DEVICE_TYPE_IOS zostanie zwrócona wartość, oznacza to, że telefon jest urządzeniem z iOS, na którym nie jest dostępny Sklep Play. Otwórz App Store na iPhonie wywołując RemoteActivityHelper.startRemoteActivity() na urządzeniu z Wear OS. Możesz określić adres URL iTunes swojej aplikacji, np. https://itunes.apple.com/us/app/yourappname.

    Z poziomu Wear OS nie możesz programowo określić, czy aplikacja na telefon jest zainstalowana na urządzeniu z iOS. Zalecamy, aby zapewnić użytkownikowi mechanizm ręcznego otwierania App Store.

Uwaga: aby określić, że dowolny adres URL ma być otwierany na telefonie z zegarka i że nie jest wymagana aplikacja na telefon, użyj interfejsu RemoteActivityHelper API zgodnie z opisem w poprzedniej sekcji.

Szczegóły wykrywania typu sparowanego telefonu

Oto fragment kodu, który używa metody getPhoneDeviceType() do sprawdzenia typu telefonu, z którym sparowany jest zegarek: 

var phoneDeviceType: Int = PhoneTypeHelper.getPhoneDeviceType(this)

Wartość zwracana przez metodę getPhoneDeviceType() jest jedną z tych:

Zwracana wartość Opis
DEVICE_TYPE_ANDROID Powiązany telefon to urządzenie z Androidem.
DEVICE_TYPE_IOS Powiązany telefon to urządzenie z iOS.
DEVICE_TYPE_UNKNOWN Powiązany telefon to nieokreślone urządzenie.
DEVICE_TYPE_ERROR Podczas określania typu sparowanego telefonu wystąpił błąd. Należy sprawdzić to później.

Wykrywanie aplikacji z poziomu telefonu z Androidem

Telefon z Androidem może wykryć, czy na urządzeniach z Wear OS użytkownika jest zainstalowana Twoja aplikacja na zegarek. Aby to zrobić:

  1. Za pomocą interfejsu NodeClient znajdź wszystkie zegarki połączone z telefonem użytkownika. Więcej informacji znajdziesz w przykładzie Datalayer helpers w GitHubie.
  2. Za pomocą interfejsu CapabilityClient, sprawdź, na których zegarkach użytkownika jest zainstalowana Twoja aplikacja.
  3. Jeśli aplikacja nie jest zainstalowana na wszystkich zegarkach użytkownika, pozwól mu otworzyć Sklep Play na pozostałych urządzeniach z Wear OS z poziomu telefonu za pomocą metody RemoteActivityHelper.startRemoteActivity(). Użyj identyfikatora URI rynku dla aplikacji na Wear OS, który może się różnić od identyfikatora URI aplikacji na telefon. Na przykład użyj identyfikatora URI rynku takiego jak: market://details?id=com.example.android.wearable.wear.finddevices.

Dane o lokalizacji zegarków sparowanych z iPhone'ami

W przypadku zegarków sparowanych z iPhone'ami użyj dostawcy uśrednionej lokalizacji (FLP), aby uzyskać dane o lokalizacji na zegarku. Więcej informacji znajdziesz w artykule Wykrywanie lokalizacji na Wear OS.

Jeśli powiązany telefon jest dostępny, FLP używa go do uzyskiwania danych o lokalizacji.

Pobieranie tylko niezbędnych danych

Zasadniczo podczas pobierania danych z internetu pobieraj tylko niezbędne dane. W przeciwnym razie możesz wprowadzić niepotrzebne opóźnienia, zużycie pamięci użycie i baterii.

Gdy zegarek jest połączony przez Bluetooth LE, aplikacja może mieć dostęp do przepustowości wynoszącej tylko 4 kilobajty na sekundę, w zależności od zegarka. Dlatego zalecamy wykonanie tych czynności:

  • Sprawdź żądania i odpowiedzi sieciowe pod kątem dodatkowych danych, które są potrzebne tylko w aplikacji na telefon.
  • Zmniejsz duże obrazy przed wysłaniem ich przez sieć na zegarek.

W przypadkach, gdy potrzebna jest sieć o dużej przepustowości, zapoznaj się z artykułem Dostęp do sieci o dużej przepustowości.

Dodatkowe przykłady kodu

Przykład Datalayer helpers dodatkowo pokazuje, jak używać interfejsów API opisanych na tej stronie.