春が来ました。 猫は猫について、男性は女性について、そしてプログラマーについて考えます-既存のコードを移植する他の場所。 昨年の秋、私はMeizu MX4 Ubuntu Editionを受賞しました。そのため、選択は長い間明白でした。 そして、時間と力がありました。
新しいプラットフォームの開発は、まずAllegroライブラリを移植し、次に-私のゲームReturn of Dr. Destructoは、すでにここで書いたもので、モバイルバージョンはiOSおよびAndroid向けにまだ開発中ですが、まもなくリリースされる予定です。
ただし、この記事ではプロジェクトを正確に移植する機能に焦点を当てるのではなく、今回出会った落とし穴を簡単に説明します。 私には2つの目標があります。1つ目は、Ubuntu Touchの初心者デベロッパーに役立つ情報を体系化して1つにまとめること、2つ目は、このプラットフォームの存在を全員に思い出させることです。それ以外の場合、リーダーの主要なペアに対して専門的なアレルギーがあります。
このプラットフォームでの私の経験は、OpenGLアプリケーションの開発のみに及ぶため、ネイティブUI(Qt)を使用することに興味がある場合は、ここではあまり面白くないことがわかります。 ただし、QtおよびQMLアプリケーションの開発については、私のタスクとは異なり、公式のリソースで十分に文書化されています(また、他のプラットフォームではgamedevを最初から忘れていました...)。
Ubuntu Touchの良いところと、それを始める方法
個人的には、ゲーム開発者として、Ubuntu Touchはまず第一に優れています。Androidとは異なり、C ++プログラムは一流の市民です。 すべてのシステムライブラリとサービスにはC ++インターフェイスがあります。ウィンドウを作成したり、支払い要求を送信したりするために、奇妙な言語でコードを記述する必要はありません。 公式のIDE-QtCreatorは、特にUIのデバッグに関して欠点がないわけではありませんが、一般的に非常に優れており、最も重要なのは、GoogleがまだAndroid Studioをねじ込めないデバイス上のC ++アプリケーションのデバッグをサポートしていることです。ビービービービー さて、iOSと比較した場合の主な利点は、Macを用意する必要がないことです(または、仮想マシンの機能が低下することで苦しみます)。
今、短所について。 まず、Ubuntuまたは多少の互換性のあるLinuxをインストールする必要があります。 そして、仮想ボックスに置くことは悪い選択肢です! QtCreatorのUbuntu Touchプラグインの開発者は、OpenGL(QtQuick)を使用してUIをレンダリングしました。その結果、Virtual Boxでは、これは非常にうまく機能しません。たとえば、QtCreatorウィンドウは常に他のウィンドウの上にあります。
Ubuntu IDEが私たちを歓迎します
また、Ubuntu自体がそれを見たという事実にもかかわらず、私はVirtual Boxで作業しようとしたときに、Ubuntu SDKでデバイスを見ることができませんでした。 しかし、ここでは、おそらく、私にはできませんでしたが、私はまだそれを理解せず、Ubuntuを実際のハードウェアに置きました。
Ubuntu Touch用のアプリケーションの開発を開始する最も簡単な方法は、Ubuntu SDKをインストールすることです。 一般的に、誰もあなたの手で必要なコンポーネントをダウンロードすることを気にしませんが、これは体に必要なものよりも苦痛であるように思えます。 SDKのインストール手順に従って 、それが存在するPPAを接続する必要があります(実際、SDKも通常のSoftware Centerにありますが、バージョンが間違っている可能性があります)。
今のところエミュレータに満足する場合は、[デバイス]タブで作成する必要があります。 プロセスは詳細に説明されていますが 、まだ動作させることができませんでした-エミュレーターは作成されたように見えましたが、そのIDEを見たくありませんでした(おそらく、プログラムがコンパイルされたものとは異なるバージョンのフレームワークを作成するときに示しました)。
デバイスで起動するには、デバイスで開発者モードを有効にする必要があります。 驚いたことに、これにはPINをインストールする必要がありました。 非常に不便で、Canonicalを除いて、Androidはそのようなゴミを作りません。
さらに、 画面がオンになっていて、ロック画面 (丸の付いた画面 )が撮影された場合にのみ、コンピューターに電話が表示されます。 興味深いことに、PINコードをダイヤルする必要はありません。
健康な人の接続デバイス
その後もデバイス(デバイス)タブのデバイスのリストに電話(またはタブレット)が表示されない場合は、同じAndroidと通信してADBの設定を編集するために登ったスキルを覚えておく必要があります(利用可能なすべてのデバイスがUbuntu Touchは基本的にAndroidデバイスです)。 投稿( 1、2 )では、デバイスのvendorIDを〜/ .android / adb_usb.iniファイルに追加することを推奨しています。
chroot、なぜUbuntu Touchでコンパイルする必要があるのか、それをどうするか
chroot、schroot、またはクリックに長年慣れている経験豊富なLinuxoidは、このセクションをスキップして、いかに哀れなwinduznikiがLinuxの力を知っているかを笑わないようにすることができます。
もちろん、アプリケーションをコンパイルするには、コンパイラー、リンカー、大量のライブラリーなど、すべてのクラウドが必要です。 これはすべて、コンパイル対象のプラットフォームで利用できるはずです。 Googleは、いくつかの環境変数を設定し、独自のビルドスクリプト(ndk-build)を作成することでこの問題を解決しました。 私が言わなければならない解決策は、「貧弱な企業」によるC ++のすべてのサポートのように、困難で外部のアセンブリシステムで動作し、信頼性が低い、かなり貧弱なことです。 しかし、プラットフォームに依存しません(まあ、理論上)。
これまでのところ、Ubuntu SDKはUbuntuでのみ機能し、失うものは何もないため、ここではすべてが異なります。 アセンブリの場合、通常のLinuxシステムを完全に反映したファイルシステムが作成されますが、ARMの場合はgcc、必要なディレクトリ内のarmhfアーキテクチャのライブラリが使用されます。 さらに、このFSはビルド時間のルートとして宣言されており、ARM Linuxのアセンブリ用に特別に調整された、このようなcな、特別に調整されたようにすべてが機能します。
これは、 chrootメカニズムを使用して実現されます。これにより、これらの非常にトリッキーなFSを操作できます。 必要なchroot'y Ubuntu SDKはコマンドで自動的に作成されるため、それらを徹底的に処理する必要はありません。 ただし、プロセスが非常に長いことに注意してください。 chroot(およびこれは約1.5Gbの多くのパッケージ)のすべてのコンテンツがネットワークからダウンロードされ、特定のアーキテクチャ(エミュレーターの場合はi386、実デバイスまたはその他のエミュレーターの場合はarmhf)およびSDKの特定のバージョン用に作成する必要があります。
興味深い部分は、標準のchrootパッケージに付属しているライブラリだけでなく、いくつかの追加のライブラリも使用することに決めたときに始まります。 ドキュメントには、chrootの配信に付属するすべてのものが常に互換性のあるバージョンで電話にあることが保証されているため、そのようなライブラリに動的に安全にリンクでき、電話のユーザーに対してすべてが機能することを期待できます。 しかし、ゲーム開発者の生活に必要なものの多くはありません:libpng、libfreetype、libogg ...これらはすべて手動で設定する必要があり、ここではchroot'ahsについてもっと知る必要があります。
実際のところ、chrootは個別の置換ファイルシステムでの動作だけでなく、そのイメージの作成もサポートしています。 通常の操作中の基本的なソーススナップショットは、何をしても同じです。 さらに、セッションを作成することができ、各セッションには独自のスナップショットソースもあります。これは、セッションがライブになるまで存続します(そして、重要なことに、この間にソースの変更が発生しても反映されません!)。 Ubuntu SDKによって作成されたセッションは、エディターの再起動後も生き残るだけでなく、コンピューターを再起動することさえできます!
chrootに新しいライブラリをインストールする正しい方法は、IDE設定の「Ubuntu」セクションの「クリック」タブにある「メンテナンス」ボタンを使用することです。 これにより、apt-get install libpng-dev:armhfなどを呼び出すことができるコンソールが提供されます。 同時に、ソースchrootのみが変更されます。 確かに、エディターがセッションを再開するかどうかはわかりません。
迷子にならないためのスクリーンショットはこちら
IDEの外部から手でchrootを登りたい、または必要なパッケージのインストールを自動でダウンロードするスクリプトを新しくダウンロードしたchrootで作成したい場合、このコマンドはドキュメントに記載されていますが 、ここでは繰り返します。私はそこに初めて会えなかったので、長い間減速していました。
chroot -a armhf -f ubuntu-sdk-15.04をクリックします。COMMANDNAMEを実行します -(ソースではなく)chroot'a内でCOMMANDNAMEを起動し、すぐに終了します。 -aオプションはchrootが作成されたアーキテクチャで、-fはSDKバージョンです。 このコマンドを使用すると、chrootに何もインストールできません(インストールされたものはすべてすぐに消えます)が、chrootファイルシステム内の何かを見つけるために、たとえばアセンブリを実行したり、検索したりできます。
chrootをクリックします-a armhf -f ubuntu-sdk-15.04 PKGNAMEのインストール-apt -get install PKGNAMEを実行し、ソースchrootを変更します
chroot -a armhf -f ubuntu-sdk-15.04 maintをクリックします。「Maintain」ボタンと同様に、コンソールを起動してソースchroot'aを変更します
そして、さらにいくつかの重要なコマンド:
schroot --list --all-sessions-すべてのアクティブなセッションのリストを表示します
schroot-セッション終了SESSION_ID-指定されたセッションを強制終了します
installまたはmaintを使用してライブラリを自分でchrootに配置する場合、Ubuntu SDKに属するセッションを強制終了することを忘れないでください。そうしないと、QtCreatorは変更が行われたことに気付きません(この日の無知のために失われました)!
最後に、私は明確にします:あなたが手でchrootに入れたものは、デフォルトでは電話にはありません! したがって、そのようなライブラリに静的にリンクするか、クリックパッケージに入れて運ぶ必要があります(必要なライブラリを指定し、システムにパッケージをインストールするときに、debを使用するときは依存関係を取得することを望みます-このようにクリックすることはできません)イデオロギー的にすることはできません)。
世界-ミール
Ubuntu Touchには使い慣れたXはありません。 それらの代わりに、長い間有望なCanonical Mirがありますが、これはまだデスクトップには届きませんが、携帯電話では-こんにちは、こちらです。 APIにより、Mirは非常にキュートです-すべてが単純で、十分に文書化されており、奇跡の奇跡です。ほとんどの関数には同期バージョンと非同期バージョンの両方があり、一般にスーパーであり、スーパーの場所はありません。 さらに、非同期関数をなんらかの方法で突然呼び出したい場合は、別の時点でその結果を待ちます。これを可能にするmir_wait_forがあります。 それはまるで人々が書いているかのようであり、普通のエイリアンではありません!
マイナスのうち、Mirクライアントの公式例がほとんど完全に存在しないことに注意する必要があります。 Wikiにあるものは 、非常に基本的なもののみを示しており、必要なもの、つまりMirSurfaceとOpenGLコンテキストを接続する方法は示していません。 幸いなことに、例は他の場所にあります。
Mir APIはこれまであまり安定していないため、上記の例はコンパイルされないことに注意してください-mir_surface_get_egl_native_window関数は存在しません。 代わりに、MirSurfaceからeglCreateWindowSurfaceと互換性のあるウィンドウを取得するには、 mir_buffer_stream_get_egl_native_windowバンチを使用します
(mir_surface_get_buffer_stream(表面)) 。
また、Ubuntu TouchはOpenGL ESの最初のバージョンをサポートしていないことに注意してください-OpenGL ES2および3のみ! 必要なリーダーとライブラリが欠落しています。 したがって、あなたが私のように、オチャコフスキーの時代のレガシーコードの周りで、クリミアの新しい征服のかなり前にいた場合、ifdefでそれをオーバーレイする必要があります。
eglChooseConfig属性リストでペアを渡すことを忘れないでください
EGL_RENDERABLE_TYPE、EGL_OPENGL_ES2_BIT
そして、eglCreateContextのコンテキスト属性のリストで-
EGL_CONTEXT_CLIENT_VERSION、2
そうしないと、BAD_CONFIGとBAD_ATTRIBUTEの重大なエラーを長時間見て驚かされます。 いまいましい、庭の21世紀、OpenGLはまだどの属性が悪いのか、そして彼が設定で気に入らなかったものを見分けることができません...
Mirの入力処理は、イベントハンドラーをインストールすることによって行われます。 これはまったく問題ありません-C ++プログラムからMirを使用する場合、コールバックとしてstd ::関数をサポートするAPIオプションを使用できます。 さて、通常のCを好むのであれば、単純な関数ポインターとvoid *コンテキストのオプションがあります。
また、MirはX11と同じキーコードを送信するため、get_key_name関数を急いでスローしないでください!
クリックする
そして、今、私たちが移植しているコードがコンパイルされ、実行する準備ができているとしましょう。 問題は、リソース、動的ライブラリ、およびその他の厄介な機能とともに、デバイスにどのように配置するかです。 Mandrake 6.0以来愛されているrpmでは、debはファッショナブルではありません。UbuntuTouchは見た目さえありませんが、新しいパッケージ形式を使用する必要があります-をクリックします。 これは、Ubuntu IDEが電話にアップロードするために収集するものです。
私の意見では、IPAやAPKと比較したクリックパッケージの重大な欠点は、ZIPではなく、独自の、トリッキーなものであるということです。 そのため、ここでそれを取得し、そこに何が詰め込まれているかを確認します。コンソールに登ってクリックキーを理解する必要があります。 ただし、もちろん、すぐに誰かがMidnight Commanderのプラグインを作成し、Click VFSがあれば、すべてが再び多かれ少なかれ良くなるでしょう。
クリックの重要な利点は、その中に何かを入れて、それを(ほとんど)何かの中に配置できることです。 パッケージの起動中にあるすべてのものは、ルートからファイルシステムとしてマウントされ、その後、任意の/ usr / localで使用するパスに沿ってライブラリとデータを検索できます。 もちろん、これは、アプリケーションが通常のLinuxからTouchに移行した場合です。 敵対的なWindowsからのゲストの場合、Linuxユーザーに馴染みのあるフォルダー構造を複製する必要はありませんが、実行可能ファイルをルートに直接配置するだけで、データが見えないように近くにあり、すべてが便利でシンプルです。 デフォルトでは、Ubuntu IDEは最初のオプションを作成しますが、CMakeまたはQMakeファイルを編集して2番目に切り替えるよう説得することは、INSTALLディレクティブに精通している場合は難しくありません。
したがって、別の微妙なポイント、または3つのポイントがあります。 クリックファイルを準備するには、次のものも必要です。
a)manifest.json-あなたのプログラムが何であるか、それがどのアーキテクチャであるか、そして何かがうまくいかない場合に誰を倒すべきかを記述したファイル。 また、フックセクションに次の2つのファイルの名前が含まれています。
b)AppName.desktop-アプリケーションが電話でどのように見えるかを記述するファイル-名前、アイコンなど -およびその動作。 後者は、たとえば、スプラッシュスクリーンの設定、および許容可能な向きに関するものです(以下を参照)
c)AppName.apparmor-プログラムが実行できることをリストするファイル(デフォルトでは、すべては許可されていません)。 AndroidManifest.xmlのアナログ許可。
ここで、少し戸惑いながら、ドキュメントが不足していることがわかります。 3つすべてのファイルの基本的な内容は問題ではありません。テンプレートまたはネットワークで確認できますが、完全を期すためにここで説明します。
manifest.json:
{ 「名前」:「APPNAME.DOMAINNAME」、 「説明」:「説明」、 「アーキテクチャ」:「ARCH」、 「タイトル」:「タイトル」、 「フック」:{ 「APPNAME」:{ 「apparmor」:「APPNAME.apparmor」、 「デスクトップ」:「APPNAME.desktop」 } }、 「バージョン」:「バージョン」、 「maintainer」:「NAME SURNAME <EMAIL@ISP.COM>」、 「フレームワーク」:「フレームワーク」 }
manifest.jsonの内容は、組み込みのUbuntu IDEエディターを使用して簡単に編集できます。
AppName.apparmor:
{ 「policy_groups」:[ 「ネットワーキング」、 ]、 「policy_version」:1.3 }
ここで、必要な権限を追加する必要があります。 これは、IDEエディターを使用する方が便利です。
AppName.desktop:
[デスクトップエントリ] _Name = VISIBLE_APP_NAME Exec = EXECUTABLE_NAME アイコン= ICON ターミナル= false タイプ=アプリケーション X-Ubuntu-Touch = true X-Ubuntu-Supported-Orientations =風景
しかし、何らかの理由でデスクトップファイルはIDEで編集されず、より正確には、テキストの形式で単純に開きます。 一見、これは問題ではありませんが、最後に、これらのX-Ubuntu-Whateverのすべてを確認すると、これらの設定の一般的な数とその内容がすぐにわかります。 新しいプラットフォームの開発者-彼らは新しい大陸の研究者に似ているので、そのようなことについて彼らに尋ねるのは、新しい大陸にいくつの川があるのかを研究者に尋ねるのと同じです-しかし、地獄は知っています。 この点に関して、Ubuntu大陸に関するドキュメントはほとんどありません。 以下が知られています:
一般的な形式のドキュメントはここから入手でき、Xフィールドではなく、多くの便利な情報が含まれています。
X-Ubuntu-Touch = [true / false] -これは、アプリケーションがデスクトップではなく電話であることを示す松葉杖です。
X-Ubuntu-Supported-Orientations = [portrait / landscape / primary] -アプリケーションで許容される画面の向き(プライマリは、携帯電話のポートレートとタブレットのランドスケープです)。 リストはここから取得されます 。 より公式なドックには最初の2つのオプションしかありません。 すべての可能な画面位置をサポートするために-このキーを指定しないでください。
X-Ubuntu-Gettext-Domain = [?] -使用する翻訳ファイルの選択に関連します。 より正確に-私は理解していませんでした、すべてがドキュメントで腐っています。
スプラッシュスクリーンの動作を制御するフィールド:
X-Ubuntu-Splash-Show-Header = [true / false] -スプラッシュ画面にアプリケーションのタイトルを表示するかどうか。
X-Ubuntu-Splash-Title = [TEXT] -タイトルに表示するテキスト。
X-Ubuntu-Splash-Image = [FILENAME] -スプラッシュ画面に表示される画像。 画像は、画面サイズに合わずに、元のサイズで表示されます。
X-Ubuntu-Splash-Color = [COLOR] -(色) QColor :: setNamedColor形式のスプラッシュスクリーンの背景色。
X-Ubuntu-Splash-Color-Header = [COLOR]およびX-Ubuntu-Splash-Color-Footer = [COLOR] -スプラッシュ画面の上部と下部の色。その間にグラデーションが作成されます。
これらの追加フィールドの一般的なリストはまだ利用できません。 Unity8ソースからそれを取得する試みはまだ成功していません-私はいくつかの設定が処理される場所を見つけましたが、残りはどこにも言及されていません-それらは動作しますが。
マニフェストファイルエディター。 デスクトップファイルでも同じようにしたい
Ubuntu IDE:CMake vs. Qmake
もちろん、経験豊富なLinuxoidは、これらすべてのIDEを軽emptし、古き良きmakeを使用してプログラムを収集し、コンソールからデバイスにインストールし、gdbでコンソールをデバッグします。 私たちは、Visual Studioやその他の神をかきたてるIDEの魅力に甘やかされており、すべてが青いグラフィカルインターフェイスを備えたプレート上にあることを望んでいます。 そのため、Ubuntu IDEを使用しようとしていますが、CMakeやQMakeなどの異質なビルドシステムも少し使用しています。
あなたがQMakeのファンで、すべてのプロジェクトで長い間使用しているなら、素晴らしいニュースがあります。UbuntuTouchでは怪我をするでしょう! load(ubuntu-click)を使用して目的のモジュールを接続し、上記のマニフェストをプロジェクトに追加すると、すべてが機能するはずです。
CMakeを使用すると、理論的にはすべてが簡単です。 Ubuntu IDEが電話でプロジェクトの実行を開始するには、CMakeLists.txtでアプリケーションのマニフェストファイルへのパスを含む次の行を指定するだけです。
設定(UBUNTU_MANIFEST_PATH "manifest.json" CACHE INTERNAL "マニフェストファイルへのパス")
非常に重要なポイント-変数がキャッシュに入ることを必ず示してください! IDEはそこでそれを探し、見つからない場合は何も言いませんが、すべてが正しく動作します。 さらに、私の実験では、CMake変数を介してマニフェストへのパスを指定できないことが示されました。 いずれにせよ、「$ {CMAKE_SOURCE_DIR} /manifest.json」の値は、何も指定しなかった場合と同じ効果をもたらしました。
さらに、奇妙なことが起こり、IDEの奇妙な振る舞いさえ言うでしょう。 すべてを正しく指定した場合でも、IDEはアプリケーションの2つの起動構成を作成します。 最初のものは、CMakeLists.txtのadd_executableで指定したものと同じです。 これは悪い、使用できない設定であり、デフォルトで選択されています! この構成では、コードとパッケージのアセンブリはARMで行われますが、IDEはこれらすべてをデスクトップで実行しようとします。 もちろん、これは彼女には機能しません(ARMデスクトップがない場合)。フォームのアプリケーション出力にエラーが表示されます。
選択されたアーキテクチャアームは、報告されているターゲットアーキテクチャi386と互換性がありません:x86-64 アーキテクチャがターゲット提供の説明を拒否しましたデバッグが終了しました
これを回避するには、プロジェクトの[プロジェクト]セクションの[実行]タブに移動して、2番目の構成に切り替える必要があります。 彼女の名前は、マニフェストファイルの「フック」セクションから取得されます。 add_executableで指定されたものと一致する場合、番号2が追加されます(たとえば、「cmake_test2」)。 これは適切な構成です。選択すると、プロジェクトはデバイス(またはエミュレーター)で実行されます。
ところで、CMakeによってコンパイルされたライブラリについてもう1つの不快な驚きが待っています。IDEセッション内でライブラリとアプリケーションの間に依存関係を構築しようとすると、成功しません。 事実、コンパイルされたライブラリのUbuntu IDEはDeployステップ(つまり、CMakeの観点からインストール)を呼び出そうとしますが、ライブラリは驚きのサプライズではmanifest.json(つまずきませんでした)がないために中断します。 開発者は、このIDEの使用方法は提供されておらず、ほとんどの場合、この点で何も変わらないと言います。 サブプロジェクトでライブラリを追加します-すべてがうまくいきます。
最初の奇妙な動作によると、Ubuntu IDE バグトラッカーにバグがありました。
「悪い」構成。 コマンドライン引数と作業フォルダ-起動パラメータに注意してください。 これは、IDEが電話ではなくデスクトップでプロジェクトを実行しようとすることを示す確かな兆候です。 起動手順のリストにある「Ubuntuデバイスにデプロイ」手順に注意を払わないでください。デバイスはデバイスにロードされる場合とロードされない場合がありますが、デスクトップでは起動されます。
「良い」構成。 ご覧のように、コマンドラインと作業フォルダの代わりに-完全に異なる設定。
これなしでどうやって生きたの?
最後に、Ubuntu Touchとは何の関係もないトリックを共有しますが、最近発見したばかりですが、少なくとも1年前には知りたいと思いました。 時々、タスクは、アプリケーションを動的ではなくライブラリの静的バージョンにリンクすることです。 もちろん、gccには-staticフラグがありますが、あまり便利ではありません(私の経験では、場合によっては機能しません)。 しかし、次のようにできることがわかります。
gcc yourprogram.o -ldynamiclib -l:libstaticLib.a
この場合、最初のライブラリ(つまり、通常は動的)と2番目のライブラリ(厳密に静的なライブラリ)が使用されます。 コロンの後に、libおよび.a!とともにFULLファイル名を指定する必要があることに注意してください。
このトリックはQMakeファイルで機能しますが、CMakeの静的ライブラリにリンクする場合は、target_link_libraries引数にlibnameではなくlibname.aを書き込むだけで、すべてが自動的に機能します。
おわりに
Ubuntu Touchの開発には、まだ困難と冒険がいっぱいです。 私の気にならなかったシステムの唯一のコンポーネントはミールでした。 主な問題は、ドキュメントがほとんど完全に欠けていることと、奇妙で予測不可能なIDEの動作です。 さらに、開発に関与するすべてのソフトウェアの絶え間ない更新は、何かを壊す可能性が常にあります(たとえば、日中にアセンブリ用に壊れたchrootがありました-しかし、完全ではありませんが、更新できませんでした。大きな時間の無駄があります)。
Ubuntu Touchとその開発に関する問題のヘルプは、次のチャネルから入手できます。
AskUbuntu-一般的なUbuntuのStackOverflow。 タッチに関する質問は回答されますが、少数であり、長い遅延があります。
Ubuntu Phoneメーリングリスト-Ubuntu Touch ユーザー向けのメーリングリスト。 開発者の質問にはほとんど答えられませんが、お使いの携帯電話に何かバグがある場合は、ここで役立つ可能性が高いです。
#ubuntu-app-devel IRC -Ubuntu Touchでの開発者間のコミュニケーションのためのIRCチャネル。Core Appsなどの経験豊富な開発者の一部に手を差し伸べることができれば、質問に答えることができるかもしれませんが、ほとんどの場合、技術的なIRCのように、致命的な沈黙があり、「空中」の質問は無視されます。ヒント:appdevsキーワードを使用して開発者をランク付けすることを恐れないでください(チャンネルトピックを参照)!
また、開発者向けのメーリングリストもありますが、まだ機能していません。 IRCにはUbuntu Touchに関連する他のチャンネルがあります。Wikiの全リストをご覧ください。
私に関しては、現在のプロジェクトの移植以外でこのプラットフォーム用に開発するかどうかはわかりません。気に入らなかったからではなく、今のところ適切なプロジェクトがもうないからです。ただし、この投稿にはまだ続編があります-新しいUbuntu Pay支払いAPIを見つけたとき、なぜ機能しないのか、アプリケーションの最小化と展開の問題、そして一般的にゲームをリリースに近い状態にする。もちろん、興味深い資料が集められない限り。
さて、そして最後に、デバイスで実行中の私のプロジェクトのスクリーンショット。ご覧のとおり、私はまだトップバーを削除できませんでした(IRCによると、これは現在のOSバージョンのバグです)