Ubuntu TouchとAndroidの相互作用の原則を学ぶ

こんにちは、Habr。

数か月前、 Ubuntu TouchをAllwinner A10プラットフォームに移植していましたが、
その過程で私は記念品としてメモを取った。 今、私の意見では、Ubuntu Touchが最終的にMirグラフィックサーバーなどに移行するまで、それらは依然として関連しています。

この記事は、興味のある人がUTとの親密な関係を始めるための出発点を見つけるのに役立ちます。

プレゼンテーションのスタイルは技術的なものとはほど遠いですが、気にしない場合は、
猫に誘います。

はじめに

libhybrisとは

libhybrisは、ライブラリをBionicユーザースペースからGlibcユーザースペースにロードできるレイヤーで、一部の文字をGlibcのオプションでオンザフライで置き換えます。 簡単に言えば、このソリューションを使用すると、Linux空間でAndroid専用のライブラリを使用できます。 もちろん、最大のメリットは、製造元がAndroid専用に作成した独自のGPUドライバーを使用できることです。

Surfaceflingerとは

surfaceflinger-ネイティブAndroidサービス、グラフィックレイヤーの複合マネージャー。



バインダーIPCとSurfaceFlingerの詳細 ：

• http://www.opersys.com/downloads/inside-androids-ui-130530.pdf
  
• http://0xlab.org/~jserv/android-binder-ipc.pdf
  
• dpolishukは素晴らしいドキュメントを共有しました-Android Binder

Ubuntu touch

Ubuntu Touch Developer Preview自体はAndroidに基づいており、ハードウェアを操作するために必要なサービスを借りています。 依存関係の一般的な概要は、 Ubuntu Touch PortingまたはOpenNetのメモにあります。

基本オペレーティングシステムとして、通常のAndroid JB 4.2が使用されるか、むしろCyagenMod-10.1 （CMサブプロジェクトのリポジトリはphablet.ubuntu.com/gitweb ）です。 dalvikとjavaに関連するものはすべて削除されました-システムサービスとHALで構成されるネイティブ部分のみが残ります。 必要に応じて、 AOSP 4.1を使用できますが、4.1のネイティブAPIに適応する準備ができており、ドキュメントや仕様によってカバーされておらず、リリースごとに異なります。

UTコンポーネントはchrootにあり、自己記述されたuchrootユーティリティが使用されます 、抜粋：

static int ubuntum(void *a) { /* Chroot */ chroot("/data/ubuntu"); chdir("/"); /* Set basic env variables */ char *const envp[8] = { "container=aal", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "SHELL=/bin/bash", "HOME=/root", "USER=root", "USERNAME=root", "LOGNAME=root", NULL }; /* Exec shell */ execle("/sbin/init", "/sbin/init", "--verbose", NULL, envp); return 0; } 

Android環境とUbuntuのchroot環境間の相互作用には、 libhybrisメカニズムが使用されます。

Ubuntu Touchコンポーネント

さまざまなUTコンポーネントからのスープは〜phablet-teamランチパッドリポジトリで見ることができます。
Androidデバイスのプラットフォームを担当する次の2つのコンポーネントに関心があります。

• プラットフォームAPI
  
• qtubuntu
  

最新のソースコードをダウンロードします。

 bzr branch lp:platform-api bzr branch lp:qtubuntu 

Ubuntu Platform API

UbuntuプラットフォームAPIは、 プラットフォームの機能（Android）を使用して基本操作を実行するための低レベルAPIです。

メソッドの例：

• ubuntu_application_ui_show_surface
• ubuntu_application_ui_hide_surface
• ubuntu_application_ui_move_surface_to
• ubuntu_application_ui_resize_surface_to

doc / mainpage.mdドキュメントファイルから、 platform-apiソースツリーは2つの部分に分割できることがわかります。

• include-抽象宣言プラットフォームAPI
• android -Android用のプラットフォームAPIの実装（Android 4.2の場合-

そして、このAPIを使用する際にサードパーティの開発者が信頼できる唯一のものは、
/ ubuntu / applicationディレクトリを含み 、他のすべてのものは時間の経過とともに変化すると予想されます。

debian / controlファイルから次のことを学びます：

 Package: libplatform-api1-hybris Depends: libhybris Description: Hybris implementation of the Platform API (runtime) This package provides the hybris implementation of the Platform API. The produced library should be used via libhybris, to communicate with the Android userspace, which is where the Ubuntu Application Manager lives. 

そう、つまり、 Android / hybris / Android.mkで判断すると、プラットフォームAPI実装は、ネイティブAndroid ライブラリとのリンクを持つlibubuntu_application_apiライブラリとして組み立てられ、Androidユーザースペースに配置されます。

 LOCAL_SRC_FILES := \ ubuntu_application_api_for_hybris.cpp \ ubuntu_application_gps_for_hybris.cpp \ ubuntu_application_sensors_for_hybris.cpp \ ../default/default_ubuntu_application_sensor.cpp \ ../default/default_ubuntu_application_ui.cpp \ ../default/default_ubuntu_ui.cpp \ application_manager.cpp LOCAL_MODULE := libubuntu_application_api LOCAL_SHARED_LIBRARIES := \ libandroidfw \ libbinder \ libutils \ libgui \ libEGL \ libGLESv2 \ libhardware \ libhardware_legacy 

platform-api / src / androidディレクトリは無人のままにされました。詳細に検討します。 CMakeLists.txtファイルの存在から判断すると、glibcのアセンブリは既に進行中です。

コードを含む1つのファイル-ubuntu_application_api.cppがあります。

 extern void *android_dlopen(const char *filename, int flag); extern void *android_dlsym(void *handle, const char *symbol); 

-libhybrisプロシージャを使用して、Androidユーザー空間から共有ライブラリから文字を動的にロードします。

 struct Bridge { static const char* path_to_library() { return "/system/lib/libubuntu_application_api.so"; } Bridge() : lib_handle(android_dlopen(path_to_library(), RTLD_LAZY)) { assert(lib_handle && "Error loading ubuntu_application_api"); } ....... void* resolve_symbol(const char* symbol) const { return android_dlsym(lib_handle, symbol); } void* lib_handle; }; 

-libubuntu_application_api.soからキャラクターをロードするためのシンプルなブリッジ。これはネイティブAndroidサービスと連携し 、 android / hybris / Android.mkを使用して最近「精神的に」組み立てました 。

 #define IMPLEMENT_VOID_FUNCTION3(symbol, arg1, arg2, arg3) \ void symbol(arg1 _1, arg2 _2, arg3 _3) { \ static void (*f)(arg1, arg2, arg3) = NULL; \ DLSYM(&f, #symbol); \ f(_1, _2, _3); } ....... IMPLEMENT_VOID_FUNCTION2(ubuntu_application_ui_init, int, char**); IMPLEMENT_FUNCTION0(StageHint, ubuntu_application_ui_setup_get_stage_hint); IMPLEMENT_FUNCTION0(FormFactorHint, ubuntu_application_ui_setup_get_form_factor_hint); IMPLEMENT_VOID_FUNCTION1(ubuntu_application_ui_start_a_new_session, SessionCredentials*); IMPLEMENT_VOID_FUNCTION2(ubuntu_application_ui_set_clipboard_content, void*, size_t); ....... 

-libubuntu_application_api.soに実装されたAPI文字のラッパーの束。

混乱を避けるために：

• libubuntu_application_api.so-バイオニック環境のライブラリで、Androidユーザースペースにあります。
• libubuntu_application_api.so -glibcの下のライブラリで、Linux userpace（chroot）に住んでいて、libhybrisを介して最初から文字をロードします。

開発者は、同じ名前のライブラリを作成することで、宇宙のエントロピーを減らすことにしました。
merge-153874ディスカッションコンポーネントの命名に関する彼らの議論を見ると、あなたの耳は消えてしまいます。

Ubuntuアプリケーションマネージャー

platform-api / android / hybrisには、UbuntuプラットフォームAPIの実装に加えて、 ubuntuappmanagerのソースがあります-Ubuntuアプリケーションサービスは、Androidユーザー空間に存在し、 Android.mkから判断して、 libubuntu_application_apiを積極的に使用し、Androidを介してBinder IPCサービスと通信します。

 LOCAL_SRC_FILES:= \ application_manager.cpp \ default_application_manager.cpp \ LOCAL_MODULE:= ubuntuappmanager LOCAL_MODULE_TAGS := optional LOCAL_SHARED_LIBRARIES := \ libbinder \ libinput \ libgui \ libskia \ libandroidfw \ libutils \ libEGL \ libGLESv2 \ libubuntu_application_api 

default_application_manager.hを簡単に見て、 多数のアプリケーションおよびセッション管理タスクを解決します。

  void update_app_lists(); void binderDied(const android::wp<android::IBinder>& who); void register_a_surface(...); void request_fullscreen(...); int get_session_pid(const android::sp<android::IApplicationManagerSession>& session); void focus_running_session_with_id(int id); void unfocus_running_sessions(); int32_t query_snapshot_layer_for_session_with_id(int id); android::IApplicationManagerSession::SurfaceProperties query_surface_properties_for_session_id(int id); void switch_focused_application_locked(size_t index_of_next_focused_app); void switch_focus_to_next_application_locked(); void kill_focused_application_locked(); void start_a_new_session( int32_t session_type, int32_t stage_hint, const android::String8& app_name, const android::String8& desktop_file, const android::sp<android::IApplicationManagerSession>& session, int fd); 

QtUbuntu

UbuntuプラットフォームAPIとQt / QMLアプリケーション間の相互作用を担当するUTの部分を扱います。

Qt Platform Abstractionに慣れていない場合、要するに、これは特別に作成されたQPAプラグインを使用してQtアプリケーションが起動されているプラ​​ットフォームから抽象化する機会です。

QPAプラグインはcreatePlatformWindowなどの基本的なメソッドを実装し、Qtアプリケーションはウィンドウを作成するときに、抽象化プラグインのcreatePlatformWindowシンボルを使用し、 そこからどこへ行っても吹き飛ばしません。

この場合、UbuntuアプリケーションAPIを操作するためのQPAプラグインを扱います。

 ~/ubuntu/qtubuntu $ tree . ├── qtubuntu.pro ├── src │ ├── modules │ │ ├── application <------------------ QML plugin    │ │ │ ├── application.cc | Ubuntu Application Manager │ │ │ ├── application.h |  QtQuick │ │ │ ├── application.pro | │ │ │ ├── application_image.cc | │ │ │ ├── application_image.h | │ │ │ ├── application_list_model.cc | │ │ │ ├── application_list_model.h | │ │ │ ├── application_manager.cc | │ │ │ ├── application_manager.h | │ │ │ ├── application_window.cc | │ │ │ ├── application_window.h | │ │ │ ├── input_filter_area.cc | │ │ │ ├── input_filter_area.h | │ │ │ ├── logging.h | │ │ │ ├── plugin.cc | │ │ │ └── qmldir | │ │ ├── ---------------------------------- │ │ └── modules.pro │ ├── platforms │ │ ├── base │ │ ├── platforms.pro │ │ └── ubuntu <-------------- QPA   │ │ ├── clipboard.cc │ │ ├── clipboard.h │ │ ├── input.cc │ │ ├── input.h │ │ ├── integration.cc <--   `createPlatformWindow`  │ │ ├── integration.h │ │ ├── main.cc │ │ ├── screen.cc │ │ ├── screen.h │ │ ├── ubuntu.json │ │ ├── ubuntu.pro │ │ ├── window.cc │ │ └── window.h │ └── src.pro └── tests 

ubuntu.proのコンテンツから判断すると、プラットフォームはlibubuntu_application_api.soの glibcバージョンとリンクしています
integration.ccおよびwindow.ccで使用されるプラットフォームAPIセットからの次のメソッド呼び出しに注意してください。

 #include <ubuntu/application/ui/ubuntu_application_ui.h> ubuntu_application_ui_start_a_new_session(&credentials); ubuntu_application_ui_destroy_surface(surface_); ubuntu_application_ui_create_surface(&surface_, "QUbuntuWindow", geometry.width(), geometry.height(), static_cast<SurfaceRole>(role), flags, eventCallback, this); ubuntu_application_ui_move_surface_to(surface_, geometry.x(), geometry.y()); ubuntu_application_ui_request_fullscreen_for_surface(surface_); ubuntu_application_ui_move_surface_to(surface_, rect.x(), rect.y()); ubuntu_application_ui_resize_surface_to(surface_, rect.width(), rect.height()); ubuntu_application_ui_request_fullscreen_for_surface(surface_); ubuntu_application_ui_show_surface(surface_); ubuntu_application_ui_hide_surface(surface_); 

これで、Qtアプリケーションがウィンドウを作成する際に、 qubuntuプラットフォームのQPAからメソッドを呼び出すことが明らかになりました-QUbuntuIntegration :: integration.ccファイルのcreatePlatformWindow ：

 QPlatformWindow* QUbuntuIntegration::createPlatformWindow(QWindow* window) { ....... // Create the window. QPlatformWindow* platformWindow = new QUbuntuWindow(.......); ....... } 

window.ccファイルのQUbuntuWindowコンストラクターを調べると、 QUbuntuWindow :: createWindow（）メソッドの呼び出しが見つかります。

 void QUbuntuWindow::createWindow() { ....... ubuntu_application_ui_create_surface( &surface_, "QUbuntuWindow", geometry.width(), geometry.height(), static_cast<SurfaceRole>(role), flags, eventCallback, this); ....... ubuntu_application_ui_move_surface_to(surface_, geometry.x(), geometry.y()); ....... } 

これは非常に簡略化されたコードですが、本質は明確です-libubuntu_application_api.soのglibcバージョンで実装したUbuntuプラットフォームAPIが呼び出されます 。これは、実際にはlibubuntu_application_api.soのバイオニックバージョンへのブリッジです。 api / android 。

ジャンプしてる？

grepを使用して目的のファイルにジャンプすると、 platform-api / android / default / default_ubuntu_application_ui.cppに移動します。

 //   ubuntu_application_ui_create_surface ubuntu::application::ui::Surface::Ptr surface = session->create_surface(props, ubuntu::application::ui::input::Listener::Ptr(new CallbackEventListener(cb, ctx))); //   ubuntu_application_ui_move_surface_to auto s = static_cast<Holder<ubuntu::application::ui::Surface::Ptr>*>(surface); s->value->move_to(x, y); 

人形を開いて、 ubuntu :: application :: ui :: Sessionおよびそれに応じて、 ubuntu :: application :: ui :: Surfaceがどのように実装されているかを確認することは残ります。 そして、それらはこのファイルに実装されています-ubuntu_application_api_for_hybris.cpp ：

 namespace android { ....... struct Session : public ubuntu::application::ui::Session, public UbuntuSurface::Observer { ....... Session(.....) { ...... ubuntu::application::ui::Surface::Ptr create_surface( const ubuntu::application::ui::SurfaceProperties& props, const ubuntu::application::ui::input::Listener::Ptr& listener) { ....... // ,     .        UbuntuSurface UbuntuSurface* surface = new UbuntuSurface(client, client_channel, looper, props, listener,this); ....... // 100%   ,    UbuntuSurface return ubuntu::application::ui::Surface::Ptr(surface); ....... 

巻き戻し、 UbuntuSurfaceを見つけます 。

 struct UbuntuSurface : public ubuntu::application::ui::Surface { ....... UbuntuSurface(const sp<SurfaceComposerClient>& client, .......) : ubuntu::application::ui::Surface(listener) { //    -    Android API surface_control = client->createSurface( String8(props.title), props.width, props.height, PIXEL_FORMAT_RGBA_8888, props.flags & .......); surface = surface_control->getSurface(); ....... 

android :: SurfaceControl型のオブジェクトを取得します。これは、 android :: SurfaceComposerClient（）-> createSurface（）の呼び出しの結果です。
android :: SurfaceComposerClient （ frameworks / native / libs / gui / Surface.cpp ）へのすべての呼び出しは、サイズ変更、移動、レイヤーの順序の変更などを通過します。

チェーンに戻って、QPAプラットフォームUbuntuで次のQtアプリケーションを起動すると実際に何が起こるかを理解します。

おわりに

私の意見では、上記で説明したUbuntu TouchとAndroidの相互作用の原理は自給自足であるため、この時点で自分を止めなければなりません。 上記のすべてとは別に、さらなる検討が既に行われている場合があります。 qmlsceneとubuntuappmanagerの相互作用の問題、 SurfaceFlingerおよびInputDispatcherサービスを使用した入力制御の原則、およびこの広範なトピックのコーナーからの他の質問は未解決のままでした。 しかし、これはまったく異なる話です。

1週間後、Firefox OSに電話が届きます。