+6Nasi autorzy
Ważne

Aplikacje z Androida na Windowsie – od kuchni

Projekt Astoria, czyli możliwość prostego przenoszenia aplikacji androidowych (pisanych w Javie i C++) do Windowsa 10 Mobile, od początku budzi skrajne emocje. Jedni cieszą się z tej możliwości, inni skazują projekt na klęskę, sugerując że i tak nikt nie będzie chciał wkładać dodatkowej pracy w przenoszenie i publikowanie appek dla Windowsa.

O szansach powodzenia tego pomysłu można bezprzedmiotowo dyskutować bawiąc się w jasnowidzów, ale dużo ciekawsze (a może tylko mi się tak wydaje?) są szczegóły techniczne samego sposobu przenoszenia aplikacji i sposobu ich działania – szczególnie pod kątem wydajności i stabilności. Już teraz słyszy się opinie, że „będą chodzić wolniej niż na urządzeniach z Androidem, bo każda emulacja czy wirtualizacja spowalnia”. To prawda, każde użycie emulatora czy maszyny wirtualnej będzie wolniejsze niż rozwiązania natywne, jeśli wykonywać będziemy te same fragmenty kodu. Widać to na przykładzie takich emulatorów Androida, jak Bluestacks dla desktopowego Windowsa, dzięki któremu możemy odpalać androidowe aplikacje w microsoftowym systemie. Nie tylko jest on wolny i zasobożerny, ale też mocno ograniczony jeśli chodzi o wsparcie dla sensorów czy urządzeń peryferyjnych.

Jest jednak jedno „ale”. Android w Windowsie Mobile nie będzie emulowany. Nie będzie osobnym systemem operacyjnym z linuksowym jądrem. Innymi słowy – aplikacje natywnie będą komunikować się z jądrem Windows NT. Nie będzie tu Androida czy Linuksa w ogóle. Oczywiście swojego rodzaju maszyna wirtualna Javy jest potrzebna (tak jak Android wykorzystuje Dalvika i ART-a), ale kod C++ będzie w 100% wykonywany natywnie. Ja to możliwe? Dzięki strukturze jądra systemu Windows i warstwowości jej komunikacji.

Zabrzmiało bardzo tajemniczo, ale żeby to lepiej zrozumieć, warto uświadomić sobie, że Windows już od dawna składał się z kilku subsystemów działających niezależnie, ale komunikujących się z tym samym jądrem. W przeszłości były to podsystemy POSIX i OS/2, ale nawet teraz mamy dwa główne podsystemy w desktopowej wersji Windowsa – Win32 (do aplikacji desktopowych) i WinRT (dla aplikacji Modern). Jeszcze raz chciałbym podkreślić, że te niezależne podsystemy komunikują się z tym samym, wspólnym jądrem, które odpowiada z kolei za komunikację ze sprzętem (w tym procesorem). Powiedzieliśmy o Windowsie desktopowym i jego dwóch podsystemach. Windows Mobile również będzie miał dwa podsystemy – WinRT (dokładnie ten sam, znany z pełnego Windowsa) oraz Android (z natywnym wykonywaniem binarek C++ oraz maszyną wirtualną Javy).

kernel

W zasadzie, dla osób mniej obeznanych w informatycznym żargonie, te informacje wystarczą, żeby zrozumieć podstawy (współ)działania aplikacji portowanych z Androida i oryginalnych aplikacji pisanych dla środowiska uruchomieniowego WinRT. Myślę jednak, ze wśród czytelników Tabletowo jest sporo osób, które chciałyby poznać ten temat głębiej. Strukturę jądra Windows NT najłatwiej zrozumieć dzięki powyższemu schematowi. Warstwa jądra (kernel mode) i i warstwa użytkownika (user mode – tu znajdują się subsystemy WinRT i Android, czyli tak zwane „enviroment subsystems”) są od siebie odseparowane. Różnią się między innymi uprawnieniami dostępu do pamięci czy czasu procesora – ze względów bezpieczeństwa, wydajności oraz stabilności. Warstwy te komunikują się ze sobą przez zarządcę pamięci wirtualnej (Virtual Memory Manager – VMM), a nad kwestiami bezpieczeństwa zajmuje się „integral susbsystem” działający równolegle do WinRT czy subsystemu Androida. Jak to ostatnie wygląda w praktyce? Pewnie słyszeliście o sandboksach, czyli „piaskownicach”, w których uruchamiane są aplikacje. Jest to narzędzie bezpieczeństwa, które niejako „oplata” proces danej aplikacji i kontroluje jego zachowanie (komunikację z innymi aplikacjami, odwołania do funkcji systemu, wymianę danych i sygnałów ze sprzętem czy sensorami, itd…). Sandboks Windowsa należy do jednych z najbezpieczniejszych i będzie on wspólny zarówno dla aplikacji WinRT, jak i subsystemu Androida. Nie ma więc ryzyka, że aplikacje androidowe „będą mniej bezpieczne” pod względem odwołań do systemu (pomijam w tym momencie dużo ważniejszy temat, czyli uprawnienia aplikacji).

astoria3

Czy Microsoft zatem użył Android Open Source Project (AOSP) i umieścił go obok swojego systemu? Jeszcze raz – nie. Trzeba podkreślić to bardzo wyraźnie – Windows 10 nie będzie korzystać z androidowego API (Application Programming Interface – zadaniem API jest dostarczenie odpowiednich specyfikacji podprogramów, struktur danych, klas obiektów i wymaganych protokołów komunikacyjnych). Jak zatem to wszystko działa? W tym momencie może narobiłem więcej zamieszania niż zdążyłem wyjaśnić, ale postaram się to naprawić. Microsoft postanowił zrobić dwie rzeczy – cały ciężar zmian i kompensacji różnic w systemach wziąć na siebie – oraz – wybrać możliwie najwydajniejszą metodę implementacji.

Tym sposobem, wybrał najpopularniejsze androidowe API, które wykorzystywane są przez aplikacje i PRZEPISAŁ je na nowo tak, żeby natywnie komunikowały się z windowsowym jądrem systemu. Innymi słowy – programista nie musi (prawie) nic zmieniać, a kontrolki czy API takie jak „udostępnij”, „lista kontaktów”, „powiadomienia”, „zadania w tle” i wszelkie odwołania systemowe zostały przepisane przez Microsoft tak, żeby pasowały do Windowsa. Podobnie jest z API dla Wideo, które będzie natywnie akcelerowane sprzętowo. Nie może tu być mowy o żadnym poświęceniu wydajności, emulacji czy drodze na skróty. Cała idea polega na zmapowaniu (przepisaniu i podmienieniu) wszystkich odwołań do systemu, które wykonują aplikacje androidowe tak, żeby były natywne wykonywane przez jądro systemu, bez dodatkowych warstw i poziomów komunikacji, które zawsze negatywnie wpływają na szybkość działania. Dotyczy to też między innymi mapowania zachowania przycisków nawigacji, regulacji głośności czy wyświetlaniu odpowiedniej „systemowej” klawiatury ekranowej, a nie klawiatury z konkurencyjnego systemu operacyjnego.

astoria1

Jak będzie zatem w teorii wyglądać przenoszenie aplikacji z Androida na Windowsa 10?

  • deweloper wysyła istniejącą androidową aplikację (.apk) na serwer Microsoftu w celu automatycznej analizy,
  • narzędzie zwraca informacje o tym, które elementy są całkowicie zgodne, które zostaną automatycznie podmienione, a które będą wymagać ręcznej zmiany (np. zamiana Google Maps na Bing czy zmiana serwera i usługi powiadomień) lub będą całkowicie niekompatybilne – to ostatnie też jest możliwe,
  • narzędzie zasugeruje pobranie SDK, czyli zestawu narzędzi programistycznych dla tworzenia aplikacji windowsowych z Androida,
  • programista w swoim środowisku programistycznym (np. Eclipse czy Android Studio) dokonuje niezbędnych zmian, opcjonalnie dodaje nowe funkcje (takie jak dynamiczne kafelki) i eksportuje projekt – dzięki ściągniętemu SDK, paczka .apk trafia do nadrzędnej paczki .AppX, która jest standardową paczką dla wszystkich aplikacji dla Windowsa 8.1 i Windowsa 10 – z automatycznym zachowaniem takich metadanych jak opis aplikacji do sklepu, cena, języki, dostępność, etc…,
  • deweloper wrzuca aplikację do Windows Store, która będzie czekać na walidację. Po walidacji będzie ona widoczna użytkownikowi dokładnie tak samo jak aplikacje pisane specjalnie dla Windowsa 10 dla subsystemu WinRT.
astoria2

Rozwiązanie idealne, tak? Nie. Po pierwsze, mapowanie API oparte jest na API dla Androida 4.4 KitKat. Co prawda większość aplikacji zapewnia zgodność aż do 4.0 a nawet wcześniej, ale w przyszłości może to być problem, szczególnie w nowych rozwiązaniach i funkcjach, które będą wyłączne dla systemu Android. Po drugie, Microsoft nie mógł zmapować (przepisać i dostosować) wszystkich API. Wybrał te najpopularniejsze, tak, żeby większość aplikacji dała się łatwo przenieść. Nie będzie na razie działać komunikacja z Android Wear, rzutowanie ekranów (”casting”) i wiele innych mniej popularnych androidowych API. Microsoft musi priorytetyzować i wybierać to, co najpotrzebniejsze. Z czasem będzie dodawał obsługę kolejnych funkcji, w zależności od zapotrzebowania na nie, ale nie możemy oczekiwać, że niektóre złożone aplikacje, korzystające z wielu sensorów czy komunikujące się z peryferiami będą łatwo portowane. Wręcz przeciwnie.

astoria4

Jest jednak też druga strona medalu. Zanim zostanę okrzyknięty fanbojem, podkreślam, że część z tego, co zaraz powiem jest daleko idącą spekulacją. Nie jest jednak spekulacją to, że subsystem Androida będzie działał w dużo bardziej hermetycznym środowisku niż w przypadku urządzeń z Androidem i Dalvika oraz ART-a. Z jednej strony może to spowodować pewne ograniczenia przy przenoszeniu aplikacji ze względu na brak uprawnień dostępu do systemu plików, smsów czy czasu procesora. Z drugiej, najprawdopodobniej przełoży się to na większe bezpieczeństwo, mniej zasobożernych aplikacji działających w tle czy większą wydajność. A co jeśli ta androidowa aplikacja przeportowana na Windowsa będzie działać szybciej, bezpieczniej i stabilniej? A nie ma żadnych technicznych przeciwwskazań, żeby moja przepowiednia się sprawdziła. Wręcz przeciwnie…

Jeżeli znalazłeś literówkę w tekście, to daj nam o tym znać zaznaczając kursorem problematyczny wyraz, bądź zdanie i przyciśnij Shift + Enter lub kliknij tutaj. Możesz też zgłosić błąd pisząc na powiadomienia@tabletowo.pl.

Komentarze

  • oloKK

    Jako laik nie wyszystko zrozumiałem, ale oby więcej takich tekstów. Dobry kierunek. A tak swoją drogą, to zaraz zlecą się hejterzy wmawiający, że Astoria to idiotyczny pomysł

    • Tomasz Lenartowski

      A niby dlaczego? Może developerzy skorzystają. Furtkę lepiej mieć niż nie mieć. I ma to szansę działać.

    • Hejter

      Astoria to idiotyczny pomysł.

  • Konrad Uroda-Darłak

    Kolejny miażdżący artykuł – brawo :D

  • arczi

    Teraz tylko czekać na Adama2 który napisze, że będzie działać wolniej, bo był pisany dla innego systemu. Nigdy nie reagował na argumenty

    • Adam2

      Będzie działać wolniej, bo Lumie mają znacznie słabsze procesory od konkurencyjnych telefonów z Androidem.

      np. Lumia 830 ma Snapdragona 400 podczas gdy kosztujące podobnie LG G2 ma dwa razy wydajniejszego Snapdragona 800 a Moto X 2nd. Gen Snapdragona 801

      • Sony

        Wystarczy optymalizacja – poczytaj o emulatorze AMIDuos – na tablecie z Windows, Atomie Bay Trail działa szybciej i płynniej niż na kosztujących 400 zł tabletach z Androidem.

        WSZYSTKO zalezy od optymalizacji – jeśli MS sypnie kasą to mozeliwe jest napisanie części kodu NAWET w Assemblerze – tak wiem, programowanie w ASM jest masakryczne, Assembler znam, programowałem sterowniki przemysłowe.

        Jak MS mocno zpotymalizuje całośc to nie zdziwię się, jak całość będzie działać lepiej niż na Androidzie :) :) – całkiem więc mozliwoe, że dobrze napisane aplikacje będą szybsze i płynniejsze nawet na słabszym sprzęcie. Pamiętajmy, że Windows jako system ma znacznie mniejsze „nażuty” niż Android. najtańszy tablet na Atomie i 1 GB RAM – identyczna konfiguracja – i Windows 8.1 dziala lepiej niż Android – porównywalem to na kosztujacych 300 zl tabletach :)

        • Tomasz Lenartowski

          Czy wiesz, że Assembler nie jest jeden dla wszystkich procesorów? Już widzę te „uniwersalne aplikacje” w Assemblerze.

          • Sony

            Nie chodzi o APLIKACJE – ale o środowisko uruchomieniowe – procesory ARM z serii Snapdragon mają ten sam kod maszynowy, podobnie jak x86 – pomijam rozszerzenia instrukcji.

            Piszemy szybkie środowisko dla Snapdragonów i drugie dla x86 – i mamy dwa projekty.

            Po za tym nie mówię o pisaniu CAŁOŚCI – ale o kluczowych fragmentach – a że jądro mamy takie same – to może się okazać, ze nie będzie to aż tak czasochłonne.

            Przykład AMIDuos dowodzi, ze można zrobić szybki i sprawny emulator Androida. A przecież AMI to znacznie mniejsza firma z dużo mniejszymi zasobami niż MS.

        • Adam2

          Porównywałem i Windows 8.1 na tablecie za 300 zł działa gorzej niż Android na Moto E za 300 zł.

          Tak że optymalizacja Windowsa 8.1 jest kiepska, a system ciężki i mułowaty.

          • Tiaa

            „Na tablecie za 300 zł” tu tkwi problem, za 300 zł. nie ma co liczyć na wydajność. Ani tu ani w androidzie. Mam swojego nexusa 7 2012 który pomimo tego, że ma w środku podobno spoko bebechy potrafi zmulić jak głupi, podczas gdy na Lumii 535 nie uświadczam żadnych lagów…

  • luther

    Panie Piotrze, skąd taka duża wiedza o systemach operacyjnych?

  • Konrad

    „Trzeba podkreślić to bardzo wyraźnie – Windows 10 nie będzie korzystać z androidowego API”

    i w następnym akapicie

    „Tym sposobem, wybrał najpopularniejsze androidowe API, które
    wykorzystywane są przez aplikacje i PRZEPISAŁ je na nowo tak, żeby
    natywnie komunikowały się z windowsowym jądrem systemu”

    To jak to będzie z tym API?

    • Dokladnie tak jak w cytacie. Przepisał na nowo API, tworząc własne odpowiedniki dla poszczególnych androidowych API

      • Konrad

        Z Wikipedii: „Zadaniem API jest dostarczenie odpowiednich specyfikacji podprogramów, struktur danych, klas obiektów i wymaganych protokołów komunikacyjnych.” lub wersja En
        „An API defines functionalities that are independent of their respective
        implementations, which allows definitions and implementations to vary
        without compromising each other”

        Jak można przepisać na nowo API androida?

        Można stworzyć nową implementację API.

        • Wytłumacz jaka to różnica w takim razie. API to kod. Przepisać na nowo / osobno zaimplementować. To zrobił Microsoft. Spór jest czysto semantyczny.

          • Expro

            API to interfejs, czyli opis, w jaki sposób aplikacja ma się porozumiewać z innym modułem (w tym przypadku – z systemem operacyjnym). Implementacja API, to kod, który pozwala się porozumiewać się z danym systemem operacyjnym. Czyli API jest jedno (nazwane akurat Android API) , ale jest wiele wiele ich implementacji – dla Windows, Android OS (czyli Linux + parę modułów), i paru emulatorów.

            Dobrą metodą jest myślenie o API jako o języku, a o implementacji jako o osobie, z którą porozumiewasz się tym językiem. Język jeden, a umożliwia rozmowę z wieloma osobami.

          • In computer programming, an application programming interface (API) is a set of routines, protocols, and tools for building software applications.

            Dalej uważam, że „spór” jest czysto semantyczny. To tak jak „program” i „implementacja programu”. API nie jest jedno. (Czesciowo) wspólne są jedynie nazwy wywolan metod. Interfejs. Różna jest natomiast backendowa implementacja. API to nie tylko frontend

          • Expro

            Niestety, nie jest to kwestia czysto semantyczna, każdy programista Ci to powie. https://en.wikipedia.org/wiki/POSIX tutaj masz dobry przykład – POSIX to API, dalej w artykule są podane implementacje (for Windows, DOS, OS/2 + certyfikowane implementacje).

    • Tomasz Lenartowski

      Dla deva funkcja będzie ta sama, tylko pod maską będzie coś innego siedziało.

  • Metek

    ” A co jeśli ta androidowa aplikacja przeportowana na Windowsa będzie działać szybciej, bezpieczniej i stabilniej? A nie ma żadnych technicznych przeciwwskazań, żeby moja przepowiednia się sprawdziła. Wręcz przeciwnie…” też tego się obawiam… :D

    • Mekateshi

      Jeśli dana aplikacja była od początku optymalizowana dla androida to raczej powinna działać taka samo.

      • Tak naprawde nie ma czegoś takiego jak „optymalizacja dla androida”. Optymalizacja to najczęściej nadużywane słowo w stosunku do kodu aplikacji.

        • Mekateshi

          Czyli mam rozumieć, że nowe wersje aplikacji tylko podnoszą ich wagę i ewentualnie zbyteczną funkcjonalność. Teraz to ma sens bo taki FB już dobił 110 MB w pamięci urządzenia – nikt go nie optymalizuje. Powoli zaczynam myśleć o telefonie z windowsem.

  • uru28

    Tekst super,bo naświetla „laikom” jak to działa.Odnośnie bezpieczeństwa pewnych kwestii niestety nie da się przeskoczyć.Jest to co prawda wspólne dla obu systemów ,choć wydaje się iż aplikacji typu „latarka” które wymagają dostępu do kontaktów i galerii zdjęć na androida jest więcej(choć może to wynikać z dysproporcji jeśli chodzi o ilość aplikacji na oba systemy). Osobiście skłaniam się ku temu, iż kwestia ilości aplikacji jest „rozdmuchana”. Wcale nie wiem czy to nie jest tak że „utarło” się że na WP nie ma aplikacji, lub jest to bardziej kwestia „mody” a nie faktycznego zestawienia. Ilościowo bezsprzecznie sklep Google bije na głowę M$, jakościowo jak dla mnie nie jest to już takie oczywiste. Analogia jest taka iż korzystając z przerobionej konsoli gry kiedyś brałem hurtowo nie patrząc na jakość, ba nawet nie spędzając 15 min z niektórymi produkcjami.Po powrocie ‚na ścieżkę prawości” i kupowaniu legalnych produkcji zacząłem wybierać tylko te najlepsze jakościowo. O ile w sklepie M$ również można znaleźć masę bezwartościowych śmieci, o tyle owe śmieci nie wieszają przynajmniej sprzętu…Oczywiście to subiektywna opinia po korzystaniu 2 lata z systemu Google i 2 lata z systemu M$.

  • Sony

    Przykład Blue Stacks jest CHYBIONY – AMIDuos działa znacznie lepiej i stabilniej. Fakt, jest płatny – ale ja po tygodniu go kupiłem – mamy 30 dniową wersję testową. Działa ZNACZNIE lepiej niz Bluestacks.

    I co WAŻNE pod Androidem działa wszystko : na Venue 11 Pro w Androidzie mam dostep do kompletu sensorów, gyro, akcelerometr – nawet stan akumulatora jest prawidłowo podawany. O GPS, WiFi, synchronizacji z kontem Google nie wspominam, bo działa.

    AMIDuos działa też szybko i płynnie, działa akceleracja, może bez problemu wymieniac pliki między Androidem a Windows. Duos nie używa wirtualizacji, działa jak normalny program.

    Porównywałem predkość działania i okazuje się, że Duos działa lepiej niż tablety na Androidzie kosztujące 800 zl. :) :) a o porównaniu do tanich tabletów nie ma mowy, AMIDuos je zjada na śniadanko.

    Kupiłę go jako ciekawostkę :) i lubie patrzyć na miny ludzi gdy widzą tablet z Windows, który po chwili zmienia się w Androida :) – i na dodatek bardzo fajnie działa :)

    • „Duos nie używa wirtualizacji, działa jak normalny program.”

      Yyyyy?

      • Sony

        Nie ma Vitrual BOX’a – AMIDuos uruchamia się „wprost na kernelu”, natywnie.

        Konkurencja najpierw odpala Vitrual Box’a, czyli wirtualną maszynę i na niej uruchamia Andruta.

        Ogólnie każdy „pośrednik” powoduje opóźnienia, komplikacje i nie potrzebie zużywa zasoby

        • niestety nie jest to prawda

          • Sony

            To jest prawda.

            AMIDuos uruchamia aplikacje natywnie w x86, a jeżeli zachodzi taka potrzeba to emuluje ARm’y. Dlatego jest taki szybki. Do tego NIE potrzebuje Virtual BOX’a jak wiele innych emulatorów.

            Nie bez przyczyny jest uznawany za jeden z najszybszych, jeśli nie najszybszy emulator.

Tabletowo.pl
Logowani/Rejestracja jest chwilowo wyłączona