Învățarea principiilor de interacțiune tactil ubuntu și Android

Cu câteva luni în urmă, am fost implicat în portarea Ubuntu Touch pe platforma Allwinner A10,
în procesul de luare notițe ca amintire. Acum, în opinia mea, ele sunt încă relevante, în timp ce Ubuntu Touch în cele din urmă sa mutat la serverul său grafic Mir și așa mai departe.

Stilul de prezentare este departe de a fi o tehnică, dar dacă nu te superi,
Vă invit o pisică.

Ce este libhybris

libhybris - un strat care permite să se încarce în glibc bibliotecă spațiul utilizator a bionic în spațiul utilizator, on-the-fly prin înlocuirea unor caractere versiuni ale glibc. Pur și simplu pune, această soluție permite utilizarea unei biblioteci de proprietate pentru Android este Linux-spațiu. Naibólshaya beneficiu, desigur, capacitatea de a folosi GPU-drivere proprietare asamblate de către producător numai sub Android.

Ce este SurfaceFlinger

SurfaceFlinger - servicii nativ de manager compozit Android straturi grafice.

ubuntu Touch

Ubuntu Touch Developer Previzualizare în sine este bazat pe Android, ea împrumută serviciile necesare pentru a lucra cu fier. O trecere în revistă a relațiilor poate fi citit aici - Ubuntu Touch Portarea sau într-o notă la OpenNet.

În condiții normale de utilizare Android JB 4.2 ca sistem de operare de bază. mai degrabă CyagenMod-10.1 (depozit sub-CM - phablet.ubuntu.com/gitweb). De la eliminat tot ce ține de Dalvik și Java - lăsând numai partea nativă, constând în servicii de sistem și HAL. AOSP 4.1 se poate folosi, dacă se dorește. dar să fie pregătiți pentru adaptarea la API nativ de 4,1, acesta nu este acoperit de nici o documentație și mai multe și caietul de sarcini se schimbă de la eliberarea pentru a elibera.

Componentele UT aranjate în chroot. samopisnaya uchroot utilitar folosit. extras:

Pentru mediile Android interacțiune și Ubuntu chroot-mediu de mecanismul implicat libhybris.

Componentele Ubuntu Touch

Supă diferitelor componente pot fi văzute în UT lanchpad-arhive

phablet-team.
Suntem interesați în următoarele două componente care sunt responsabile pentru activitatea pe platforma Android:

Platforma-api
qtubuntu

Descărcați cea mai recentă versiune de cod sursă:

Ubuntu Platform API

Ubuntu platforma API - API-nivel scăzut pentru a efectua operațiuni de bază cu utilizarea platformei (Android) caracteristici.

Exemple de metode:

ubuntu_application_ui_show_surface
ubuntu_application_ui_hide_surface
ubuntu_application_ui_move_surface_to
ubuntu_application_ui_resize_surface_to

Din documentația de fișier doc / mainpage.md afla că sursa de copac platforma-api poate fi împărțită în două părți:

includ - abstract platforma declarație API
Android - punerea în aplicare platforma API pentru Android (mi-ar fi spus - pentru Android 4.2)

Și singurul lucru pe care se poate baza pe dezvoltatori terți pentru a lucra cu API - antetele
include / ubuntu directorul / aplicație. și tot ceea ce implică o schimbare a lungul timpului.

Da, așa că, judecând după Android / hybris / Android.mk. Platforma de implementare API este colectată ca bibloteki libubuntu_application_api erori de legătură cu android libami nativ și plasat în spațiul utilizator android:

Fără atenție a rămas director platforma-api / src / Android. uita-te la ea în detaliu. Judecând după fișierul prezență CMakeLists.txt. de asamblare a fost întâmplă pentru glibc.

Există doar un singur fișier de cod - ubuntu_application_api.cpp. caută în care vom vedea:
- Proceduri de utilizare libhybris pentru a încărca dinamic simboluri de partajat-libs din spațiul utilizator android.

- simplu pod simbolurilor de încărcare de la libubuntu_application_api.so. care devine, împreună cu serviciile Android native, iar noi recent mental „colectate“ de Android / hybris / Android.mk.

- o grămadă de ambalaje pentru simbolurile API puse în aplicare în libubuntu_application_api.so.

Deci, pentru a evita confuzia:

libubuntu_application_api.so - Biblioteca sub bionic, trăiește în spațiul rezervat utilizatorului Android;
libubuntu_application_api.so - Biblioteca sub glibc, trăiește în userpace Linux (chroot), caracterele prima navă prin libhybris.

Dezvoltatorii au decis să reducă entropia universului prin crearea acelorași biblioteci nume.
Dacă te uiți la dezbaterea asupra componentelor de denumire fuziona-153874 discuție. urechile se ofilesc.

Ubuntu Application Manager

Platforma-api / Android / hybris, în plus față de punerea în aplicare a Ubuntu surse platforma API sunt ubuntuappmanager - servicii de aplicații Ubuntu, el trăiește în spațiul utilizator a Android și judecând după Android.mk. utilizează în mod activ libubuntu_application_api si comunica prin intermediul Binder IPC cu servicii de android.

Se rezolvă o grămadă de aplicații și sesiuni de control, o privire rapidă la default_application_manager.h:

Cercetat cu partea UT, responsabilă de interacțiunea dintre Ubuntu platforma API și aplicații Qt / QML.

Dacă nu sunteți familiarizați cu Qt Platforma abstractizare. apoi, pe scurt, este abilitatea de a face abstracție de platforma pe care aplicațiile Qt rula prin intermediul unui scrise special QPA-in-uri.

QPA-plugin pus în aplicare metode de bază, cum ar fi createPlatformWindow. și apoi aplicarea Qt atunci când vrea să creeze o fereastră folosind createPlatformWindow simbol al abstractizare și conectați mustața nu sufla, în cazul în care a mers acolo.

În acest caz, avem de-a face cu un plug de QPA pentru a fi utilizat cu Ubuntu aplicație API.

Judecând după ubuntu.pro de conținut. link-ul de la platforma glibc-versiunea libubuntu_application_api.so
Să acorde o atenție la următoarele apeluri de metode dintr-un set de platforme API, utilizate în integration.cc și window.cc:

Acum este clar că atunci când cererea noastră Qt vrea să creeze o fereastră, aceasta va determina metoda platformei QPA qubuntu - QUbuntuIntegration :: integration.cc createPlatformWindow a fișierului:

Privind la QUbuntuWindow de designer în fișierul window.cc. Gasim provocare QUbuntuWindow :: createWindow metoda ():

Acesta este un cod extrem de dezbrăcat în jos, dar punctul este clar - pentru a efectua apeluri la platforma API-ul Ubuntu. pe care am implementat în glibc-versiunea libubuntu_application_api.so. că, de fapt, este un pod la bionic-versiunea libubuntu_application_api.so. cod care este în platforma-api / Android.

Rămâne Matryoshka deschisă și pentru a găsi cât de bine ubuntu implementate :: aplicatie :: :: Sesiunea și interfața de utilizare, în consecință, ubuntu :: aplicatie :: :: Surface UI. Și acestea sunt puse în aplicare în acest fișier - ubuntu_application_api_for_hybris.cpp:

Reînfășoară, găsi UbuntuSurface:

Obținem un obiect de tip android :: SurfaceControl. care este rezultatul de asteptare Android :: SurfaceComposerClient () -> createSurface ().
Prin ea trece toate cererile de la Android :: SurfaceComposerClient (cadre / nativ / libs / gui / Surface.cpp), cum ar fi redimensionarea, mutarea, schimbarea ordinii straturilor și așa mai departe.

Mergând înapoi de-a lungul lanțului, înțelegem ce se întâmplă cu adevărat atunci când vom lansa următoarea Qt platformă de aplicații QPA Ubuntu.

concluzie

În acest moment trebuie să mă opresc pentru că, în opinia noastră, luarea în considerare a principiilor de interacțiune a Ubuntu Touch și Android este autosuficientă. Alte argumente ar putea să meargă în mod izolat din toate cele de mai sus. Nerasmotrennymi au întrebări și ubuntuappmanager interacțiune qmlscene. Principiul de control de intrare cu ajutorul serviciilor SurfaceFlinger InputDispatcher și alte probleme din colțurile acestei fire prostoronoy. Dar asta e altă poveste.