Jak projekty OEM centrów inteligentnego domu wybierają między architekturami Androida AOSP i GMS

Gdy firmy opracowują hub Domowy Inteligentny , architektura systemu Android jest często ustalana znacznie wcześniej niż etap produkcji sprzętu.

W pierwszym ujęciu wyświetlacz centrum sterowania domem może wyglądać jak standardowe urządzenie dotykowe. Jednak w wielu projektach B2B wyświetlacz nie jest po prostu ekranem z systemem operacyjnym. Staje się dedykowanym interfejsem łączącym usługi oprogramowania, użytkowników oraz połączone środowisko domowe.

Dlatego niektórzy zakupujący zaczynają zadawać głębsze pytania dotyczące Architekturze Android : Czy urządzenie powinno korzystać ze standardowego systemu Android z usługami Google Mobile Services ( Gms )? Czy projekt wymaga systemu AOSP -oparty na systemie bez usług Google? Jak duży stopień kontroli nad wdrażaniem oprogramowania i zachowaniem urządzeń potrzebuje zakupujący?

Trzy rzeczywiste zapytania od producentów sprzętu domowego (OEM) z Norwegii, Belgii i Stanów Zjednoczonych stanowią przydatne przykłady. Nie oddają one całej rynkowej różnorodności rozwiązań dla inteligentnych domów, ale pokazują, jak różni zakupujący oceniają wymagania systemowe w oparciu o własne cele wdrożeniowe.

Istotnym sygnałem nie jest fakt, że każdy projekt inteligentnego domu przesuwa się w kierunku wyświetlaczy bez usług Google zamiast tego te zapytania pokazują, że zakupujący stają się coraz bardziej precyzyjni w zakresie kontroli oprogramowania, wdrażania aplikacji oraz dostosowywania urządzeń.

Dlaczego niektóre projekty inteligentnych centrów sterujących wymagają większej kontroli nad systemami Android

Tradycyjna tabletowa platforma konsumencka jest zaprojektowana z myślą o elastyczności. Użytkownicy instalują różne aplikacje, uzyskują dostęp do usług internetowych oraz współdziałają z szerokim ekosystemem.

Dedykowany inteligentny hub do domu wykorzystuje inną logikę. W wielu projektach OEM urządzenie ma jedno główne przeznaczenie: niezawodne uruchamianie określonej aplikacji w kontrolowanym środowisku.

Klient może wymagać, aby wyświetlacz uruchamiał się bezpośrednio w jego własnym oprogramowaniu, zapobiegał niepotrzebnemu dostępowi użytkownika lub zapewniał spójne zachowanie we wszystkich wdrożonych jednostkach. W takich przypadkach architektura Android staje się decyzją biznesową, a nie tylko wyborem technicznym.

An AOSP -oparte rozwiązanie umożliwia głębszą kontrolę nad środowiskiem systemowym, podczas gdy rozwiązanie Gms android z włączoną funkcją zapewnia dostęp do ekosystemu i usług Google. Żadna z tych opcji nie jest uniwersalnie lepsza. Odpowiedni wybór zależy od sposobu wdrażania, obsługi i użytkowania urządzenia.

Ta różnica ma szczególne znaczenie dla firm przechodzących z oprogramowania na sprzęt. Na przykład firma SaaS budująca dedykowany inteligentny wyświetlacz może mniej interesować się ogólną funkcjonalnością systemu Android i bardziej tą, czy sprzęt może niezawodnie zapewnić oczekiwane doświadczenie użytkownika z oprogramowania.

Trzy żądania OEM-ów ilustrują różne powody dostosowywania systemu Android

Te przykłady odzwierciedlają rzeczywiste dyskusje OEM-ów z zakupującymi w różnych regionach rynku. Zamiast skupiać się na poszczególnych firmach, porównanie podkreśla, jak różne cele projektowe wpływają na wybór systemu Android, wdrażanie oprogramowania oraz wymagania dotyczące dostosowania sprzętu.

Jeden norweski integrator systemów zażądał wyświetlacza opartego na AOSP bez Gms oraz ograniczeń sprzętowych, takich jak usunięcie komponentów kamery i mikrofonu. Projekt wymagał również trybu kioskowego z automatycznym uruchamianiem plików APK.

To żądanie wyraźnie wskazuje na preferencję kontrolowanego środowiska Android. Klient nie szukał ogólnego tabletu, lecz dedykowanego terminala sprzętowego, w którym doświadczenie użytkownika związane z oprogramowaniem można było zarządzać na poziomie systemu.

Jednak powód stojący za tym żądaniem należy nadal zweryfikować podczas dyskusji projektowych. Wymaganie Bez GMS może wynikać z oczekiwań dotyczących prywatności, kontroli aplikacji, zasad wdrażania w środowisku korporacyjnym lub innych, specyficznych dla danego projektu uwarunkowań.

Drugi projekt, z belgijskiego dostawcy rozwiązań opiekuńczych dla osób starszych, skupiał się na innych priorytetach. Żądane funkcje obejmowały łączność 4G, WiFi, trybu kioskowego gPS

W przeciwieństwie do pierwszego projektu ten klient nie wymagał jawnie systemu bez Google. Ta różnica ma istotne znaczenie, ponieważ pokazuje, że dostosowanie Androida z naciskiem na prywatność nie jest automatycznie wymagane w każdym przypadku zastosowania w inteligentnych domach lub rozwiązaniach opiekuńczych dla osób starszych.

Trzeci projekt pochodził od amerykańskiej firmy SaaS badającej wdrożenie sprzętu do swojej usługi oprogramowania. Główne wymagania obejmowały wstępne zainstalowanie aplikacji, wdrożenie trybu kioskowego oraz dostosowanie marki.

Dla firm oprogramowania przechodzących na sprzęt fizyczny wyzwaniem często nie jest wybór specyfikacji tabletu. Większym wyzwaniem jest stworzenie niezawodnego interfejsu fizycznego, który rozszerza istniejącą platformę oprogramowania.

W tych trzech przykładach wspólnym wymaganiem nie był koniecznie system Android pozbawiony usług Google. Wspólnym wymaganiem było większe kontrolowanie sposobu działania oprogramowania na dedykowanym sprzęcie.

Odpowiednia architektura systemu Android zależy od tego, kto kontroluje doświadczenie użytkownika z oprogramowaniem.

Decyzja między AOSP i Gms powinno zaczynać się od modelu aplikacji, a nie od preferencji systemu operacyjnego.

Dla projektów opartych w dużej mierze na usługach Google, aplikacjach konsumentów lub istniejącym ekosystemie Androida system Android z obsługą GMS może zapewnić praktyczne zalety dzięki szerszej zgodność z zastosowaniem .

Dla dedykowanych terminali, w których zakupujący kontroluje środowisko aplikacji, system oparty na AOSP może zapewnić większą elastyczność. Jest to szczególnie istotne, gdy urządzenie wymaga dostosowanego zachowania podczas uruchamiania, ograniczonego dostępu użytkownika lub długotrwałej spójności oprogramowania.

Różnica wpływa również na proces rozwoju OEM. Dostosowany projekt Androida może obejmować więcej niż zmianę interfejsu użytkownika. Może wpływać na  konfigurację oprogramowania układowego , zarządzanie obrazem systemu, przepływ wdrażania aplikacji , Strategię aktualizacji OTA , oraz weryfikacja produkcji .

Dla zakupujących pytanie brzmi więc nie po prostu:

"Czy ten dostawca może dostarczyć tablet z systemem Android?"

Ważniejsze pytanie brzmi:

"Czy ten dostawca może obsługiwać pełny model wdrożenia sprzętu i oprogramowania wymagany przez nasz projekt?"

Wymagania dotyczące prywatności należy zweryfikować, a nie zakładać

Żądania takie jak „bez GMS”, „bez aparatu fotograficznego” lub „bez mikrofonu” często przyciągają uwagę, ponieważ mogą wskazywać na wyższe oczekiwania dotyczące prywatności.

Jednak dokładne motywy nie powinny być zakładaane.

W trzech przeanalizowanych projektach tylko jeden nabywca jawnie zażądał Bez GMS  AOSP środowiska. W pozostałych dwóch projektach tego wymagania nie wspomniano.

Oznacza to, że dostosowania skupione na prywatności pojawiają się w konkretnych scenariuszach nabywców, a nie stanowią uniwersalnego wymogu dla wszystkich centrów inteligentnego domu.

Dla dostawców i nabywców wcześniejsze rozmowy powinny wyjaśnić, czy projekt wymaga całkowicie kontrolowanego środowiska Android, czy usługi Google są niezbędne oraz czy ograniczenia sprzętowe wiążą się z oczekiwaniami dotyczącymi prywatności, rozważaniami związanymi z zgodnością czy pozycjonowaniem produktu.

Weryfikacja tych wymagań na wczesnym etapie może zmniejszyć zbędną pracę inżynierską i uniknąć kosztownych zmian po rozpoczęciu rozwoju.

Wdrożenia trybu kioskowego stają się podstawą dedykowanych inteligentnych wyświetlaczy

Chociaż trzej nabywcy mieli różne priorytety, wszystkie projekty miały podobny kierunek: wyświetlacz musiał funkcjonować jako dedykowany interfejs usługi.

To jest miejsce trybu kioskowego staje się ważny. Pozwala na automatyczne uruchamianie aplikacji, ograniczony dostęp użytkowników oraz spójne wrażenia po wdrożeniu.

W systemach opieki nad osobami starszymi, inteligentnych centrach domowych oraz produktach sprzętowo-opartych na oprogramowaniu wyświetlacz nie jest już tylko ekranem z systemem Android. Staje się częścią kompleksowego systemu usług.

Powstają także nowe wymagania dla dostawców OEM. Wsparcie takich projektów wymaga nie tylko zrozumienia specyfikacji sprzętowych, ale również integracja oprogramowania i sprzętu w fazach rozwoju, produkcji oraz długotrwałej eksploatacji.

Zanim rozpoczniesz projekt OEM inteligentnego wyświetlacza, najpierw zdefiniuj te decyzje

Zanim poprosisz o Rozwiązanie OEM z wyświetlaczem z systemem Android nabywcy powinni najpierw jednoznacznie określić cztery granice projektu:

Czy aplikacja zależy od usług Google, jak duży stopień kontroli nad systemem Android jest wymagany, czy istnieją ograniczenia związane z prywatnością oraz jak urządzenie będzie zarządzane po wdrożeniu.

Te decyzje bezpośrednio wpływają na odpowiednią platformę sprzętową, architekturę Androida, zakres dostosowań oraz wymagania dotyczące możliwości dostawcy.

Ocena dostawcy powinna więc wykraczać poza specyfikacje procesora, pamięci lub wyświetlacza. Zamawiający powinni upewnić się, czy partner OEM może zapewnić wsparcie dla dostosowanie systemu wdrażania aplikacji, zarządzania oprogramowaniem układowym oraz długoterminowego utrzymania produktu.

Trzy rzeczywiste potrzeby omówione w tym artykule nie dowodzą, że każdy projekt inteligentnego domu wymaga wyświetlaczy bez usług Google . Ilustrują one bardziej praktyczną zmianę: zamawiający coraz częściej oceniają sprzęt pod kątem jego zdolności do wspierania ich strategii oprogramowania.

Dla firm rozwijających centralki inteligentnego domu , wyświetlacze do opieki nad osobami starszymi lub produkty sprzętowe sterowane oprogramowaniem, wcześniejsze zdefiniowanie odpowiedniej architektury systemu Android może zmniejszyć ryzyko rozwoju i zapewnić bardziej niezawodną ścieżkę wdrażania.

Jeśli planujesz projekt inteligentnego wyświetlacza opartego na systemie Android, wcześniejsze zdefiniowanie odpowiedniej architektury systemu może pomóc zmniejszyć ryzyko rozwoju oraz uniknąć niepotrzebnych kosztów dostosowania.

Nasz zespół może pomóc ocenić wymagania dotyczące Twojej aplikacji, opcje architektury systemu Android (AOSP lub GMS) oraz potrzeby dostosowania sprzętu, aby określić odpowiednie podejście do wdrożenia.

Skontaktuj się z naszym zespołem aby omówić wymagania związane z Twoim projektem lub przesłać zapytanie dotyczące spersonalizowanego rozwiązania wyświetlaczowego opartego na systemie Android.