Chodzi o Windows 10 Mobile i Project Astoria, który ma umożliwić przenoszenie aplikacji z Androida na smartfony z Windowsem.
Do tej pory wszystkie oficjalne źródła Microsoftu mówiły o Astorii jako o projekcie, który będzie pracował nad („on top of”) jądrem Windows NT. Androidowe miało być tylko środowisko uruchomieniowe z bibliotekami i maszyną wirtualną Javy. Odpakowanie i dekompilacja pewnych plików systemowych z Windows 10 Mobile pozwoliła jednak na dostrzeżenie kilku ciekawych szczegółów.
Na początek chciałbym podkreślić, że nadal nie wiadomo w 100% jak to wszystko będzie ze sobą współpracować, ale wszystko w wskazuje na to, że jednym z elementów nowego jądra Windowsa 10 Mobile będzie linuksowy kernel. Narzędzie do wyszukiwania tekstów w kodzie binarnym pozwoliło na wyodrębnienie następujących stringów:
- Linux version 3.4.0-Microsoft ([email protected]) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Dec 31 14:42:53 PST 2014
- initrd=/initrd.img root=/dev/ram0 rw androidboot.hardware=hyperv console=tty0 console=ttyS0 video=hyperv_fb:1024×768 BOOT_IMAGE=/kernel
Architektura podsystemu Androida w Windowsie mogłaby wyglądać tak (sugerując się wyciekłą dokumentacją Astorii) – gdzie AOW = Android on Windows:
Nadal nie wiadomo dlaczego zdecydowano się na zastosowanie elementów (jak obszernych?) linuksowego kernela w jądrze W10M. Być może przesądziły kwestie wydajnościowe, kompatybilnościowe lub potrzeba wsparcia dla wybranych technologii – na myśl przychodzi mi na przykład Qt. Sam kontener, w którym znajduje się cały runtime mocno przypomina mi ideę Pico-procesów znaną z projektu Drawbridge. Drawbridge był prototypem mechanizmu wirtualizacji umożliwiającym osiągnięcie separacji aplikacji oraz jądra ze względów bezpieczeństwa (sandboxing). Pico-procesy zapewniają izolację samego procesu od innych procesów (aplikacji) z minimalnym narzutem API nad jądrem systemu. Drugim elementem jest ograniczony do minimum system operacyjny (właściwie zbiór bibliotek) działający w kontekście uruchomieniowym aplikacji. Choć jądro linuksowe tak naprawdę ogranicza się tutaj do przekierowywania wywołań systemowych, żeby ostatecznie wywołać kernel Windows NT.
Brzmi to dość skomplikowanie i nadal nie ma 100% pewności, że taka jest właśnie architektura Androida w Windowsie 10 Mobile. Ważne jest jednak to, że do tej pory wydawało się, że Astoria to tylko maszyna wirtualna pozwalająca na uruchamianie aplikacji Javowych w W10M. W świetle powyższego jednak, wszystko wskazuje na to, że mamy do czynienia niemalże z całym gołym Androidem i jego bibliotekami uwięzionymi w mechanizmach bezpieczeństwa i separacji systemu Windows. Z całym jego dobrodziejstwem – w tym OpenGL czy silnikiem Webkit.
Niesie to ze sobą ważne implikacje. Po pierwsze, appki które nie korzystają z Google Services (na przykład mapy, powiadomienia, logowanie kontem Google) i API z nimi związanych – nie będą wymagać żadnych zmian w kodzie. Wystarczy, że programista zapakuje gotową paczkę .apk w windowsową paczkę .Appx i wrzuci ją do sklepu Windows Store. Mało tego – jeśli ktoś zdecyduje się na deweloperskie odblokowanie telefonu z W10M, będzie mógł instalować aplikację („po kablu USB”) wprost z androidowych paczek .apk. Oczywiście bez problemów będą działać tylko te, które nie korzystają z Google Services. Te korzystające będą musiały być odpowiednio zmodyfikowane przez deweloperów.
A trzeba pamiętać, że skoro mamy do czynienia z licencją GPL, Microsoft będzie musiał w końcu udostępnić kod źródłowy całego tego mechanizmu Linux-w-Windowsie…
źródło: wpxap
