Digital Signage Open ADB: wdrażanie aplikacji Android własności klienta

Kiedy projekt digital signage obejmuje aplikację należącą do klienta na Androida, wybór wyświetlacza digital signage na Androidzie nie jest już tylko kwestią rozmiaru ekranu, rozdzielczości czy metody montażu. Ważniejszym pytaniem jest, czy platforma Android daje integratorowi wystarczającą kontrolę do wdrażania i uruchamiania własnego oprogramowania.

Stało się to jasne, gdy dystrybutor digital signage z Bośni zwrócił się do nas z zapytaniem o kompaktowy wyświetlacz na Androida. Zamierzone zastosowanie obejmowało wyświetlanie informacji, ale klient miał już własną aplikację na Androida i nie chciał być ograniczony przez fabrycznie zainstalowany Launcher. Prośba obejmowała otwarty ADB, instalację APK po stronie klienta, możliwość użycia aplikacji klienta jako Launchera oraz stojak odpowiedni do różnych orientacji instalacji.

W przypadku tego typu projektu najpierw analizujemy wymagania dotyczące wdrażania oprogramowania. Praktyczne pytania są proste: Czy APK klienta można zainstalować niezależnie? Czy jego aplikacja może stać się Launcherem urządzenia? Czy ta konfiguracja pozostanie po ponownym uruchomieniu? I jaki poziom dostępu do systemu jest dostępny, jeśli integrator potrzebuje zarządzać środowiskiem Android?

Te pytania skłoniły nas do oceny wyświetlacza jako platformy Android, a nie tylko jako urządzenia do odtwarzania treści.

Klient potrzebował czegoś więcej niż fabrycznego środowiska Android

Konwencjonalne wdrożenie digital signage może w dużej mierze opierać się na oprogramowaniu dostarczanym z wyświetlaczem. Treści mogą być dostarczane za pośrednictwem systemu CMS, uruchamiane za pomocą aplikacji fabrycznej i zarządzane w ramach zamierzonego przepływu pracy producenta.

Integrator z własną aplikacją ma inne wymagania. Wyświetlacz staje się częścią istniejącego środowiska oprogramowania integratora, więc możliwość wdrażania samodzielnie zainstalowanego APK staje się częścią procesu wyboru sprzętu.

W tym przypadku wymaganie nie polegało jedynie na jednorazowej instalacji aplikacji. Klient chciał, aby jego własne oprogramowanie stało się normalnym interfejsem prezentowanym użytkownikom.

Ta różnica zmieniła sposób, w jaki podeszliśmy do zapytania. Zamiast traktować „Android” jako wystarczającą specyfikację, podzieliliśmy wdrożenie na kilka praktycznych warstw: dostęp ADB, instalacja APK, niestandardowe zachowanie Launchera, zachowanie przy uruchamianiu i dostęp Root.

Nasza potwierdzona konfiguracja digital signage na Androida obsługuje te wymagania. Obsługiwany jest ADB, klient może zainstalować własny APK za pomocą ADB, aplikacja z wymaganą właściwością Launchera może zastąpić oryginalny Launcher, a skonfigurowany Launcher pozostaje domyślnym punktem wejścia po ponownym uruchomieniu. Root jest również otwarty domyślnie, z adb shell działającym z uprawnieniami Root.

Dla kompaktowego środowiska aplikacji, wyświetlacz 10,1-calowy RK3588 Android 13 stanowi odpowiedni przykład sprzętowy wyświetlacza digital signage na Androidzie 13 z procesorem RK3588. Wykorzystuje procesor RK3588 i Androida 13 i jest pozycjonowany jako wyświetlacz na Androida dla aplikacji wymagających integracji oprogramowania i dostosowywania.

Sam produkt nie jest głównym punktem tej sprawy. Ważne jest to, że sprzęt może pomieścić kontrolowane przez klienta środowisko oprogramowania, zamiast wymagać od integratora budowania swojej aplikacji wokół stałego interfejsu fabrycznego.

Otwarty ADB umożliwia wdrażanie APK po stronie klienta

Dla integratora z istniejącą aplikacją na Androida, pierwszym praktycznym pytaniem jest, czy oprogramowanie można wdrożyć bez polegania na fabrycznie zainstalowanym środowisku aplikacji producenta. Na przykład, w przypadku wyświetlacza informacyjnego, wdrożenie może rozpocząć się od 21-calowego tabletu / komputera typu all-in-one z ekranem dotykowym RK3399 na Androidzie działającego z własnym APK klienta.

Otwarty ADB zapewnia kanał dostępu używany do komunikacji z urządzeniem z Androidem z komputera. W tym scenariuszu wdrożenia, odpowiednią możliwością jest to, że klient może używać ADB do instalacji własnego APK.

Jest to czasami określane jako wdrażanie APK przez side-loading. Aplikacja jest dostarczana przez klienta, a nie ograniczona do oprogramowania preinstalowanego przez producenta wyświetlacza.

ADB, instalacja APK i Root powinny być nadal traktowane jako oddzielne możliwości. ADB jest mechanizmem komunikacji. Instalacja APK jest operacją wdrażania. Root określa poziom uprawnień dostępny w systemie Android.

Rozróżnienie to ma znaczenie podczas zakupu, ponieważ wyświetlacz może obsługiwać Androida, a nawet umożliwiać instalację aplikacji, nie zapewniając jednocześnie poziomu dostępu do systemu wymaganego przez integratora.

W konfiguracji potwierdzonej dla naszej linii produktów digital signage na Androida, klient może używać ADB do instalacji własnego APK, podczas gdy dostęp Root jest dostępny domyślnie. Daje to integratorowi jasną ścieżkę wdrażania własnego oprogramowania i, w razie potrzeby, głębszy dostęp do środowiska Android.

Dla kupujących poszukujących możliwości samodzielnej instalacji APK na wyświetlaczach digital signage na Androidzie — lub planujących zainstalować własny APK na wyświetlaczu digital signage — jest to bardziej użyteczne rozróżnienie niż po prostu szukanie wersji Androida w arkuszu specyfikacji.

Ważny krok następuje po instalacji APK

Instalacja APK nie sprawia automatycznie, że ta aplikacja staje się głównym interfejsem urządzenia.

Było to ważne dla klienta. Klient miał już własną aplikację i nie chciał, aby użytkownicy przechodzili przez fabryczny Launcher przed dotarciem do tej aplikacji.

Aplikacja na Androida z odpowiednią właściwością Launcher/Home może być skonfigurowana jako domyślny Launcher urządzenia. Gdy stanie się domyślnym Launcherem, aplikacja klienta staje się normalnym punktem wejścia do systemu Android.

Potwierdzona konfiguracja obsługuje to podejście. Gdy aplikacja klienta ma wymaganą właściwość Launchera, może zastąpić oryginalny Launcher, zamieniając urządzenie w wyświetlacz digital signage z niestandardowym launcherem na Androidzie. Po ponownym uruchomieniu urządzenia skonfigurowany Launcher pozostaje domyślny, a urządzenie może ponownie wejść do aplikacji klienta.

Tworzy to znaczącą różnicę między dwoma typami projektów digital signage z samodzielną instalacją APK na Androidzie.

W jednym modelu klient po prostu instaluje aplikację obok oprogramowania producenta. W drugim aplikacja klienta staje się głównym interfejsem urządzenia. Drugi model jest bliższy temu, czego potrzebuje wielu integratorów, gdy wyświetlacz ma działać jako część własnego środowiska aplikacji.

Rozróżnienie to jest również powodem, dla którego „obsługiwana instalacja APK” nie powinna być traktowana jako kompletna odpowiedź przy ocenie projektu digital signage z niestandardowym launcherem.

Dostęp Root zapewnia integratorowi głębszą opcję na poziomie systemu

Wymaganie klienta obejmowało również otwarty dostęp do systemu, co jest miejscem, w którym Root staje się istotny.

Potwierdzona konfiguracja zapewnia dostęp Root domyślnie. Bardziej szczegółowo, adb shell działa jako Root, a nie jako ograniczony użytkownik powłoki.

Nie oznacza to, że Root jest wymagany tylko do instalacji APK klienta. Wdrażanie APK i Root to oddzielne części systemu.

Powodem wyjaśnienia Root podczas zakupu jest coś innego: integrator może potrzebować głębszego dostępu podczas adaptacji, konfiguracji, debugowania lub zarządzania własnym środowiskiem oprogramowania. Do tych zadań, 12-calowy tablet przemysłowy RK3288 na Androidzie z NFC i uchwytem ściennym oferuje kompaktową platformę do montażu na ścianie z obsługą SDK do niestandardowej integracji.

W przypadku tego typu projektu rozróżnienie można wyrazić prosto:

Dlatego też nie opisujemy wymagań dotyczących wyświetlaczy typu kiosk z otwartym ADB po prostu jako wymagania Root. Projekt może potrzebować ADB i niestandardowego Launchera, nie wymagając, aby wszystkie funkcje systemu były dostępne dla użytkownika.

Niestandardowy Launcher i Kiosk są powiązane, ale nie identyczne

Niestandardowy Launcher rozwiązuje jedną ważną część doświadczenia użytkownika: pozwala aplikacji klienta stać się normalnym interfejsem Home.

Bardziej rygorystyczne wdrożenie Kiosk może wymagać czegoś więcej. Aplikacja może pozostać jedynym praktycznym środowiskiem skierowanym do użytkownika, podczas gdy normalna nawigacja do pulpitu Androida lub ustawień systemowych jest ograniczona — wzorzec istotny dla wdrożeń samoobsługowych, takich jak nasza seria kas fiskalnych POS.

Te wymagania powinny być definiowane oddzielnie.

Dla potwierdzonej konfiguracji omówionej w tym przypadku, aplikacja klienta może stać się domyślnym Launcherem, gdy ma wymaganą właściwość Launchera, a urządzenie może powrócić do tej aplikacji po ponownym uruchomieniu. To ustala pozycję aplikacji jako głównego interfejsu urządzenia.

Jeśli projekt dodatkowo wymaga ścisłego blokowania aplikacji, ograniczonej nawigacji systemowej lub określonej implementacji zarządzania urządzeniem, te wymagania powinny być oceniane zgodnie z aplikacją klienta i metodą wdrożenia, a nie zakładane jako zawarte tylko dlatego, że obsługiwany jest niestandardowy Launcher.

To rozróżnienie jest szczególnie istotne dla integratorów budujących własne środowisko oprogramowania Kiosk. Właściwe pytanie nie brzmi po prostu, czy wyświetlacz jest reklamowany jako wyświetlacz kiosk na Androida dla niestandardowych aplikacji, ale które części doświadczenia użytkownika Androida aplikacja klienta faktycznie potrzebuje kontrolować. Wdrożenie samoobsługowe, takie jak 11,6-calowy kiosk na Androidzie POS pokazuje aplikację klienta działającą jako główny interfejs na platformie Android.

Fizyczny wyświetlacz nadal musi pasować do aplikacji

Konfiguracja oprogramowania była tylko częścią pierwotnego zapytania. Klient potrzebował również kompaktowego wyświetlacza i stojaka, który mógłby pomieścić różne orientacje.

To wymaganie wykracza poza konfigurację Launchera. Aplikacja może być zaprojektowana do prezentacji w pionie lub poziomie, ale fizyczna konstrukcja nadal określa sposób pozycjonowania wyświetlacza.

Dla kompaktowego środowiska aplikacji, wyświetlacz 10,1-calowy RK3588 Android 13 stanowi odpowiedni przykład sprzętowy. Wykorzystuje procesor RK3588 i Androida 13 i jest pozycjonowany jako wyświetlacz na Androida dla aplikacji wymagających integracji oprogramowania i dostosowywania.

Sam produkt nie jest głównym punktem tej sprawy. Ważne jest to, że sprzęt może pomieścić kontrolowane przez klienta środowisko oprogramowania, zamiast wymagać od integratora budowania swojej aplikacji wokół stałego interfejsu fabrycznego.

Dla kompaktowego wyświetlacza digital signage na Androidzie, konfiguracja 10,1-calowa jest bliższa pierwotnemu wymaganiu. 15,6-calowy tablet z Androidem FHD IPS z RK3288 i 13,3-calowy tablet all-in-one z Androidem z ekranem FHD IPS i RK3288 mieszczą się między formatami kompaktowymi a dużymi dla zastosowań signage i kiosk. Dla aplikacji wymagających większej powierzchni interaktywnej i mobilnej instalacji, 21,5-calowy wyświetlacz Stand By Me na Androidzie z RK3588 oferuje inny format fizyczny, wykorzystując to samo ogólne podejście do platformy Android.

Powodem rozdzielenia tych dwóch rozważań jest praktyczność. Elastyczność oprogramowania nie determinuje automatycznie instalacji mechanicznej. Projekt wymagający umieszczenia w poziomie i pionie nadal potrzebuje odpowiedniej struktury fizycznej, mechanizmu obrotowego lub konfiguracji stojaka.

Z tego powodu nasza linia wyświetlaczy reklamowych na Androidzie obejmuje różne formaty wyświetlaczy komercyjnych, które można oceniać zgodnie ze środowiskiem aplikacji — w tym większe panele wewnętrzne, takie jak 24-calowy tablet all-in-one RJ45 PoE na Androidzie z jasnością 350cd/m².

Jak pomogliśmy przetłumaczyć wymaganie na konfigurowalne wdrożenie

Przydatną częścią tego typu projektu nie jest tylko potwierdzenie, że wyświetlacz działa na Androidzie. Wyzwaniem jest połączenie istniejącego oprogramowania klienta ze środowiskiem sprzętowym, w którym będzie ono działać.

Dla dystrybutora z Bośni, wymaganie można było przetłumaczyć na sekwencję praktycznych pytań: jak APK dotrze do urządzenia, czy aplikacja może stać się Launcherem, co dzieje się po ponownym uruchomieniu i jaki poziom dostępu do Androida ma integrator?

Po rozdzieleniu tych pytań, wymaganie dotyczące sprzętu stało się znacznie jaśniejsze.

Potwierdzona możliwość można podsumować w następujący sposób:

Jest to część procesu, która może zmniejszyć niepewność dla integratora. Zamiast najpierw wybierać wyświetlacz i odkrywać ograniczenia oprogramowania później, wymaganie dotyczące oprogramowania może być wykorzystane do określenia, czy platforma jest odpowiednia dla projektu wyświetlacza digital signage na Androidzie z otwartym ADB i dostępem root, zanim przejdzie dalej do wdrożenia. To samo podejście można zastosować do projektu digital signage z otwartym ADB, w którym aplikacja klienta już istnieje, a głównym wymaganiem jest wdrożenie tego oprogramowania na komercyjnym wyświetlaczu Androida.

Praktyczny punkt wyjścia dla własnego projektu digital signage na Androidzie

Aplikacja należąca do klienta zmienia sposób oceny wyświetlacza na Androida. Rozmiar ekranu i specyfikacje wyświetlacza nadal mają znaczenie, ale są tylko częścią decyzji o wdrożeniu.

Dla integratora, bardziej użyteczna ocena zaczyna się od aplikacji: czy APK musi być zainstalowany niezależnie, czy aplikacja musi stać się Launcherem, czy musi automatycznie pojawić się po ponownym uruchomieniu i czy wymagany jest głębszy dostęp do systemu.

To było podstawą naszego podejścia do zapytania z Bośni. Zamiast traktować otwarty ADB, instalację APK, zachowanie Launchera i Root jako niepowiązane specyfikacje, ocenialiśmy je jako części tego samego wymagania dotyczącego wdrażania oprogramowania.

Jeśli Twój projekt ma już własny APK na Androida, następnym krokiem jest zdefiniowanie oczekiwanego zachowania aplikacji i dopasowanie go do odpowiedniej konfiguracji wyświetlacza digital signage na Androidzie. Przykładowe urządzenie może być następnie użyte do walidacji APK, zachowania Launchera, zachowania po ponownym uruchomieniu i wymaganego dostępu do systemu przed przejściem do szerszego wdrożenia. Ten sam wzorzec wdrażania dotyczy aplikacji wyświetlaczy na Androidzie, od paneli rezerwacji sal konferencyjnych po ekrany zamawiania w restauracjach, co odzwierciedlają nasze serie tabletów do rezerwacji sal konferencyjnych i tabletów do zamawiania w restauracjach. Jeśli oceniasz podobne wdrożenie wyświetlacza na Androidzie, skontaktuj się z naszym zespołem, aby omówić wymagania dotyczące APK i konfigurację urządzenia.