Când vorbim despre "Android development", cei mai mulți se gândesc la aplicațiile mobile care rulează pe telefoane sau tablete. Dar în ultimii ani, ecosistemul Android s-a extins dincolo de buzunarul nostru, a ajuns în mașini, televizoare, ceasuri și chiar electrocasnice. Totuși, una dintre cele mai interesante și complexe ramuri este Android Automotive OS — o platformă dedicată industriei auto. Deși împart aceleași rădăcini, dezvoltarea Android clasică și cea Android Automotive diferă semnificativ în scop, arhitectură, instrumente și experiența dezvoltatorului.
Procesul tipic pentru o aplicație Android urmează o linie clară:
Conceperea de produs. Definirea funcționalităților, UI/UX design, și arhitectura de bază (MVVM, MVI etc.);
Implementare. Folosind Android Studio, Jetpack Libraries și API-urile standard (Activity, Fragment, ViewModel, LiveData, Compose);
Build & Test. Pipeline-ul local folosește Gradle, care gestionează dependențele, build types (debug, release), și product flavors (pentru versiuni free/premium sau regionale);
Semnare și împachetare. Aplicația este semnată cu o cheie proprie, generând un APK sau AAB (Android App Bundle);
În Android clasic, Gradle permite lansarea simultană de versiuni diferite ale aplicației, optimizate pentru testare internă sau producție. În unele cazuri, dezvoltatorii sau OEM-urile mobile integrează în ROM aplicații deja compilate, cunoscute drept prebuilt apps.
Acestea sunt APK-uri semnate anterior, incluse direct în imaginea de sistem, de exemplu, aplicații Google, de muzică, browsere web, jocuri etc. Pentru dezvoltarea aplicațiilor mobile, conceptul de prebuilt e mai rar întâlnit, apărând doar atunci când OEM-ul sau integratorul livrează un sistem Android personalizat, cum ar fi One UI, MIUI sau OxygenOS. Telefoanele Pixel, de asemenea, vin cu întregul pachet de aplicații tip Prebuilt GAS. Însă un dezvoltator de aplicații mobile Android, dacă nu are de a face cu platforma AOSP sau AAOS, nu se va referi niciodată la ele ca Prebuilt. Pentru el, asta este normalitatea.
Pentru dezvoltarea în AAOS, conceptul de Prebuilt este foarte des întâlnit. Pe lângă acestea, în AAOS mai sunt și aplicațiile de tip platformă, care se caracterizează prin codul sursă existent direct în platformă și compilat doar o dată cu compilarea întregii platformei.
În mediul mobil, testarea se concentrează pe unit tests, scrise de regulă folosind Junit, MockK sau Mockito, instrumentation tests, scrise în Espresso pentru interacțiunea și validarea UI, urmând în final closed / open testing în Play Console - pentru feedback real de la utilizatori. Publicarea unei aplicații Android se face prin Play Console, unde dezvoltatorul încarcă APK/AAB, definește țările de distribuție, configurează politici de confidențialitate, permisiuni și reclame, setează canalul de release (internal, closed, open, production) și apoi urmărește metricele post-lansare (crash reports, ANRs, ratings etc.). De aici începe faza de mentenanță și iterare continuă, dar nu mai există obstacole de certificare sau aprobare externe. Spre deosebire de Automotive, unde fiecare build trebuie validat de OEM și Google, în Android clasic publicarea este instantanee și controlul este complet al dezvoltatorului. Ciclul de QA este iterativ, cu release-uri săptămânale sau chiar zilnice față de Automotive, unde un release poate dura luni și trece prin certificare.
Atât Android cât și Android Automotive sunt construite pe același nucleu open-source - AOSP (Android Open Source Project). Aceasta oferă un framework comun (Java/Kotlin API-uri, sistem de permisiuni, servicii de bază precum ActivityManager, PackageManager etc.). Cu alte cuvinte, un dezvoltator Android se va simți "acasă" atunci când deschide un proiect Automotive: limbajul, structura aplicației și multe API-uri familiare sunt încă acolo. Dar asemănările se opresc destul de repede.
Android Automotive OS (AAOS) este un sistem de operare complet integrat în vehicul, nu doar o interfață proiectată de pe telefon (cum este Android Auto). AAOS rulează direct pe hardware-ul mașinii, fiind conectat la rețelele CAN, sistemele de infotainment, climatizare, senzori și camere. Aici, aplicațiile fac parte dintr-un ecosistem vital pentru siguranță. De exemplu, o aplicație poate controla temperatura în cabină, poate afișa presiunea anvelopelor sau poate ajusta luminozitatea în funcție de condițiile de drum. Mai mult, în Android Automotive OS (AAOS), dezvoltatorul lucrează cu întreaga platformă Android, nu doar cu aplicațiile. Asta înseamnă acces la codul AOSP (Android Open Source Project) și extinderea lui pentru Automotive (AAOS), build system-ul Soong, configurațiile device, vendor și product și chiar la codul HAL (Hardware Abstraction Layer) cu extensia sa pentru mașini VHAL (Vehicle HAL). Cu alte cuvinte, nu mai construiești doar un APK, ci construiești un sistem de operare complet.
Un pipeline tipic de dezvoltare AAOS implică mai multe etape. Deoarece avem nevoie de mult mai multe repository-uri de cod pentru zecile de aplicații, servicii ș.a., se folosește unealta repo ce primește ca parametru un fișier de tip xml cunoscut sub numele de manifest, unde sunt declarate toate aceste repository-uri, alături de locația unde se dorește clonarea și branchul de pe care se dorește clonarea.
repo init -u
https://android.googlesource.com/platform/manifest
-b android-14.0.0_r3Urmează apoi sincronizarea codului după rețeta dorită. În primă fază, va dura mai mult, fiind de la început. Însă ulterior, repo va identifica doar diferențele și va dura mai puțin.
repo sync -j$(nproc)Setarea mediului de build se face prin încărcarea în sesiunea curentă de terminal a variabilelor utilitare procesului de build și alegerea variantei dorite spre construire:
source build/envsetup.sh
lunch aosp_car_x86_64-userdebugPasul final este pornirea procesului de build în sine din rădăcină prin comanda următoare. Aceasta va trece recursiv prin toate fișierele copil și va identifica fișierele de tip .mk sau .bp unde sunt descrise rețetele de build (dependințe, permisiuni etc.) pentru fiecare subcomponentă clonată și sincronizată anterior, relevantă pentru varianta dorită spre construire:
m -j$(nproc)Acest pas creează un set complet de imagini (system.img, vendor.img, boot.img) care definesc sistemul AAOS. Rularea pe un device real necesită scripturi de flash a imaginilor generate după ce pui device-ul în modul fastboot
adb reboot bootloader
fastboot flash system system.img
fastboot flash vendor vendor.img
…Android a trecut de la clasicul Make la Soong, un sistem bazat pe Blueprints și Ninja, scris în Go, dar suportă în continuare și sistemul Kati bazat pe Makefiles. Soong procesează fișierele Android.bp (echivalent modern al Android.mk) pentru fiecare modul (app, library, HAL etc.), generând o grafică completă de dependențe.
Un exemplu simplu de Android.bp:
android_app {
name: "MyAutomotiveApp",
srcs: ["src/**/*.java"],
sdk_version: "system_current",
privileged: true,
certificate: "platform",
}Acest mecanism permite builduri extrem de precise, controlate per module, per device și per produs. Pentru OEM-uri, acest lucru este crucial — fiecare brand de mașină poate partaja același cod de bază, dar cu builduri specifice (de exemplu, volvo_car.mk, polestar_car.mk etc).
Emulatorul Automotive nu este același cu cel mobil. Google oferă o imagine AAOS AVD care trebuie instalată manual în SDK Manager, dar poate fi și creată din sursa locală. În SDK Manager (\$ANDROID_SDK_ROOT/system-images/), emulatorul este definit printr-un fișier XML din avd/ precum:
<avd>
<name>Sparq_x86_64</name>
<path>~/.android/avd/Sparq_x86_64.avd</path>
<target>android-34</target>
<tag>android-automotive</tag>
<abi>x86_64</abi>
<device>automotive_1080p</device>
</avd>Emulatorul oferă UI-ul auto standard și acces limitat la API-urile android.car.*, dar fără comunicația completă CAN (disponibilă doar pe hardware real).
Pentru dezvoltarea Automotive, similar cu mobile, userdebug este standardul de facto. El permite testarea aplicațiilor cu acces la adb, logcat și servicii interne (precum CarService), dar simulează totuși comportamentul unui sistem sigur. În final, pe mașină, va veni pus un build de tip user, care este buildul de producție, semnat și fără acces root.
Buildurile Automotive sunt gestionate prin pipeline-uri complexe, care includ:
Repo sync automat din manifestul AOSP extins pentru mașini + manifest OEM;
Build orchestration (Jenkins, GitHub Actions, GitLab Enterprise etc.);
Instrumented tests & Integration tests rulate pe emulator sau hardware farm;
Semnare și versionare OTA;
Aceste pipeline-uri sunt adesea private, dar respectă aceleași principii ca în Android Open Source, cu adăugarea unor etape stricte de validare și certificare hardware, dar și software.
Într-o aplicație Android clasică, scopul este livrarea unei experiențe rapide și fluide. Într-o aplicație Automotive, accentul se mută pe arhitectură robustă și comunicare cu subsisteme. Menționăm în acest sens operații precum, accesarea datelor prin CarPropertyManager sau ascultarea evenimentelor vehiculului (viteză, climat, baterie, etc.). Adesea, aplicațiile sunt dezvoltate în colaborare cu echipele OEM și implică lucrul cu platforme interne, builduri personalizate și integrări cu middleware auto 3rd party precum Qualcomm.
După ce am înțeles cum se construiește și se personalizează Android Automotive OS (AAOS), următorul pas firesc este să explorăm cum funcționează platforma intern — serviciile, HAL-urile și interfețele care transformă un sistem Android într-un ecosistem auto complet.
În Android Automotive, CarService este componenta cheie care face legătura între aplicațiile de nivel înalt și sistemul vehiculului. Acesta rulează ca un system service și expune un set de API-uri prin android.car.*, disponibile aplicațiilor privilegiate.
adb shell cmd car_serviceAceastă comandă permite interogarea și controlul componentelor interne — de exemplu, statusul sesiunii de conducere, proprietăți CAN sau configurări de user.
Din cod, accesul se face prin:
val car = Car.createCar(context)
val carPropertyManager = car.getCarManager(Car.PROPERTY_SERVICE) as CarPropertyManager
val speed = carPropertyManager.getFloatProperty(VehiclePropertyIds.PERF_VEHICLE_SPEED, 0)CarService orchestrează mai multe subsisteme precum CarAudioService, CarSensorService, CarPowerManagementService, CarPropertyService (interfață către Vehicle HAL), CarUserService (multi-user management), etc.
Vehicle HAL (Hardware Abstraction Layer) este stratul care face legătura între Android și ECU-urile fizice ale mașinii. Este implementat de producătorul vehiculului, conform specificației IVehicle.aidl, structura tipică fiind:
hardware/interfaces/automotive/vehicle/aidl/IVehicle.aidlAcest HAL definește o serie de proprietăți (Vehicle Properties), fiecare identificată printr-un ID unic (VehiclePropertyIds), spre exemplu PERF_VEHICLE_SPEED, ENGINE_RPM, HVAC_TEMPERATURE_SET, GEAR_SELECTION, DOOR_LOCK_STATUS
Când o aplicație citește viteza, de exemplu, lanțul complet este:
App → CarService → CarPropertyService → Vehicle HAL → ECUOEM-ul poate extinde HAL-ul standard prin Vendor Extensions, adăugând propriile proprietăți (de exemplu, VENDOR_TRAILER_MODE_STATUS).
Spre deosebire de Android Mobile, în Automotive fiecare șofer are un profil separat, cu preferințe, aplicații și setări personalizate. CarUserService gestionează logica de creare, comutare și ștergere a userilor, legată de cheia fizică a mașinii sau de contul Google.
În Automotive, siguranța și stabilitatea sunt cruciale. Un crash pe telefon poate fi o neplăcere; un crash pe un sistem de infotainment dintr-o mașină poate însemna pierderea accesului la funcții importante. De aceea, aplicațiile și serviciile sunt supuse unor procese stricte de testare, certificare și conformitate (inclusiv norme precum ISO 26262 pentru siguranță funcțională). Android Automotive are vaste posibilități și cerințe stricte de logare. Ele sunt disponibile și pentru dezvoltarea aplicațiilor pentru telefon sau tabletă, însă sunt extinse și folosite cu mai mare atenție. Câteva dintre acestea sunt logd, statsd, Perfetto pentru telemetrie și performanță. OEM-urile folosesc aceste date în pipeline-uri de test automatizate și verifică timpii de boot, latența între input și acțiune, stabilitatea comunicației CAN, memory leaks, rate de crash și watchdog events ș.a.
O parte esențială în dezvoltarea AAOS o reprezintă brand customization. Acest lucru se realizează prin Overlays XML pentru UI (res/values/configs.xml, themes.xml), Brand-specific packages adăugate în product makefiles sau chiar implementări customizate precum SystemUI Services. Astfel, fiecare brand își păstrează identitatea vizuală, fără a devia de la arhitectura AAOS. În lumea auto, un OEM (de exemplu, Sparq) poate avea mai multe branduri (Speeder, Alpinist, Transporter), toate bazate pe același AOSP + AAOS.
Customizarea se face la nivel de:
*device*/ - fișiere specifice hardware-ului (de exemplu, device/Sparq/transporter/);
*product*/ - configurații software (teme, aplicații, pachete default);
*vendor*/ - drivere și HAL-uri specifice ECU-ului;
Un exemplu de product definition:
PRODUCT_NAME := sparq_car
PRODUCT_BRAND := Sparq
PRODUCT_MODEL := Transporter
PRODUCT_PACKAGES += SparqLauncher SparqSettingsPrin acest mecanism, OEM-ul poate produce zeci de imagini distincte din același cod sursă, păstrând consistența arhitecturală, dar adaptând brandul și experiența UI.
GAS este un set de servicii și aplicații certificate de Google, care adaugă funcționalități esențiale la nivel de sistem și utilizator final. În lipsa acestui pachet, Android Automotive rămâne o platformă completă, dar fără integrarea ecosistemului Google. Google acordă licența GAS, permițând preinstalarea aplicațiilor și accesul la Play Store, după trecerea testelor xTS. xTS este o denumire generică pentru suitele de testare Android folosite în procesul de certificare. Pentru Automotive, acestea sunt extinse și specializate.
Într-o mașină fără GAS nu există Play Store, iar aplicațiile se livrează prin canalele oferite de OEM. Nu există Google Maps, dar se folosesc soluții alternative (de exemplu, TomTom, HERE, Sygic etc). Nu există Assistant, dar OEM-ul poate folosi alternative precum Amazon Alexa, Cerence sau o soluție proprie.
Pentru OEM-uri, decizia între a avea sau nu GAS este una strategică, deoarece cu GAS câștigi acces la ecosistemul Google, dar pierzi controlul complet asupra software-ului și ești supus unor verificări amănunțite. În schimb, fără GAS ai libertate totală, dar ești responsabil pentru întreaga experiență, fiind necesară căutarea alternativelor produselor pachetului GAS. Indiferent de alegere, ambele rămân variante sunt Android Automotive OS.
Un laborator 3PL pentru GAS trebuie să îndeplinească cerințele stabilite de Google pentru a valida dacă un sistem infotainment Android Automotive este compatibil și sigur pentru a include serviciile Google. Are acces la suitele de testare xTS și instrumentele aferente (CTS, VTS, ATS, STS etc.), dar și capacitatea de a rula testele pe hardware real și de a furniza rapoarte conforme cu cerințele Google. Deține controlul proceselor de testare, audit, securitate și integritate (pentru a asigura că testele sunt corect implementate). Dispune de infrastructura necesară (e.g. ferme de dispozitive, monitorizare climatică), având acorduri contractuale cu Google pentru confidențialitate, suport și livrare de rapoarte oficiale. Nu în ultimul rând, are posibilitatea de a oferi suport OEM-urilor în analiza problemelor și triere de buguri. În general, OEM-ul nu poate pur și simplu să execute testele intern și să pretindă certificarea GAS, ci trebuie să lucreze cu un laborator acreditat.
P3 Group a fost recunoscut oficial ca un laborator 3PL acreditat de Google pentru testare și certificarea sistemelor Android Automotive.
Concluzie
Dacă în Automotive vorbim despre procese mai stufoase, pipeline-uri complexe și certificări rigide, în Android development clasic totul este construit pentru a permite oricui — de la start-up la corporație — să construiască, să testeze și să publice aplicații într-un timp scurt.
Google investește constant în extinderea Android Automotive, iar tot mai mulți producători adoptă platforma. Dezvoltarea pentru Automotive rămâne o nișă, necesitând o înțelegere profundă a domeniului auto. Dezvoltarea pură Android și cea pentru mașini folosind Android Automotive OS împarte ADN-ul tehnologic și o mare parte din codul sursă, însă sunt câteva diferențe. Dezvoltarea pentru Android Automotive nu înseamnă doar "scriere de aplicații Android pentru mașini", ci construirea unui sistem de operare complet, adaptat unui mediu critic, cu pipeline-uri controlate, builduri incrementale și un proces riguros de validare. Dacă în Android clasic totul e despre viteză și UX, în Automotive totul este despre stabilitate, siguranță și integrare.