Xused Framework については、XDA リーダーについて説明する必要はありません。 私たちのコミュニティについて尋ねられたとき ロリポップが一番嫌い、ディスカッションで最も多くの票を集めたコメントは、Xused のサポートを打ち切るというものでした。 実際、多くのフォーラム メンバーは特にこの理由で Lollipop へのアップデートを拒否しています。 しかし、待望の Xused Framework がついに Android Lollipop に登場したため、すべてが変わりました。
Xused にまだ慣れていない方のために、簡単に言えば、これはモッディング コミュニティへの天の恵みです。 Xused では ROM をフラッシュする必要はありませんが、ユーザーが root 化されたデバイスにアプリと同様にインストールできる大量のカスタマイズと微調整が提供されます。 使い方は非常に簡単で、リスクも限られています。 そして今、Lollipop のすべての Android 愛好家は、自分のデバイスでこの素晴らしいプロジェクトの恩恵を享受できるようになりました。 ダウンロードを入手して、改造を始めましょう!
rovo89 さんも親切にも最新プロジェクトに関する Q&A を提供していただきました。 プロジェクトに関するすべての質問に対する回答は以下で見つけることができます。
なぜそんなに時間がかかったのでしょうか? ART は 1 年以上前に公開されました。
まず第一に、多くの人が ART サポートを求め続けています。 Lollipop には、さらに厳格な SELinux ポリシー、64 ビット ROM、メジャー リリースに期待されるアーキテクチャの変更など、それよりもはるかに多くの変更が加えられています。 そしてもちろん、ART 自体は常に改善されています。 ART for KitKat と ART for Lollipop の間には大きな違いがあります。
その理由の 1 つは、研究、開発、テストに非常に多くの時間の作業が必要となる、非常に複雑な点です。
もう 1 つの理由は、私の生活には Xused 以外のことがあり、コードをまったく見ていない数週間、場合によっては数か月があったことです。
すべてのモジュールを書き直す必要がありますか?
いいえ、Xused API はほとんど変わっていません。 Xused はすべての詳細を抽象化するため、モジュールは Dalvik で実行されているか ART で実行されているかを気にする必要がありません。 多くのモジュール、特にユーザー アプリの動作を変更するモジュールは、実際には何も変更せずに動作します。 システム動作を対象とするモジュールは、新しい Android フレームワーク コードに合わせて調整する必要がある場合があります。 これは ART が原因ではなく、単に 2 つの Android 間で発生したアーキテクチャとコードの変更によって引き起こされます。 リリースします。 最も重要なのは、システム サービスのコードが別のファイルに移動されたことです。 影響を受けるモジュールのほとんどは、少しのリファクタリング (コードを別の場所に移動する) で解決できます。
実際に機能しているのでしょうか？
はい！ 少なくとも私にとっては、普段使っているデバイス (CM12 上の Nexus 5) だけでなく、Nexus 9 (XDA によって支払われました - ありがとう!) でも問題なく動作しています。 携帯電話はいつものように安定しており、アプリも正常に動作しています。 そして明らかに、モジュールとそのフック/リソース置換も同様に正常に動作しています。そうでなければ、何かをリリースする意味がありません。
では、なぜアルファ版なのでしょうか?
前回の安定版リリース以降、大きな変更が加えられているため、リカバリの使用方法、ブート ループからの脱出方法、バグの適切な報告方法を知っている人がテストする必要があります。 初心者には、十分な経験を積んだ人によって Xused がテストされるまで待つことを強くお勧めします。
JNI (ネイティブ) メソッドのフックやフック時に実行されるメソッドなど、まだテストされていないエッジケースもいくつかあります。
インストールしたいです。 今！ 何をしなければなりませんか?
上記の私の言葉を読んで、携帯電話の内部構造についてよく理解していることを確認してください。 明らかに、Lollipop ROM を使用し、データを適切にバックアップする必要があります。 現時点では、ARMv7 バージョンのみを公開します。 64 ビットはより複雑なので、最初は「簡単な」バージョンを試してみましょう。
現時点では、インストールはカスタム リカバリで手動で実行する必要があります。 zip ファイルをフラッシュすると、以下がインストールされます。
- app_process32_xused といくつかのシンボリックリンク
- libexused_art.so
- libart.so およびいくつかの関連バイナリ + ライブラリ (5.0.2 ベース、フックなどのサポートで強化)
- XusedBridge.jar (現在は /system/framework に保存されています)
既存のファイルのバックアップは自動的に作成され、後で復元できます。
うまくいかない/気に入らない! どうすればアンインストールできますか?
最も簡単な方法は、バックアップを復元するか、システム パーティションをフラッシュすることです。 アンインストール用のzipファイルはまだ作成されていません。
私のデバイス上の ART ファイルを置き換えるのはなぜですか? これは Dalvik よりも侵襲的であり、パフォーマンスに重大な問題を引き起こし、不安定になります。
いくつか理由を書きましたが、 GitHub. はい、それはより侵襲的であるため、私は長い間それを避けようとしてきましたが、技術的およびサポート指向の観点からは、それがより良い選択肢だと思います。
本来のARTよりも性能が落ちる？ おそらく、特定の種類のフックを可能にするためにいくつかの最適化を無効にする必要があったためです。 ただし、これが影響するのはすべてのメソッドのほんの一部であり、それらのメソッドであっても、パフォーマンスの低下は、測定可能な場合でも、重大または顕著ではありません。 ART によって実行されるその他の最適化はまだ何千もあり、可能な限りの柔軟性を提供しながら、無効にする最適化をできる限り少なくするように努めました。
安定性は前述の通り良好です。 Dalvik で使用したアプローチ (ランタイムの内部データ構造を変更する) と比較してください。 app_process))、ライブラリを完全に置き換えた方がはるかに信頼性が高いとさえ確信しています。 方法。 変更を既存のコードにきれいに統合し、関連する関数を再利用することができましたが、他の方法では多くのハックと仮定が必要になります。
ついにソースコードを公開するのか？
確かに、アルファ版のリリース後すぐに、GitHub で別のブランチで見つけることができます。
これは、古い Android バージョンはサポートされなくなったということでしょうか?
いいえ！ 新しいコードは Android のすべての 4.x バージョンでコンパイルできるため、統合リリースの前にテストするだけで済みます。 ただし、まず、Lollipop が正常に動作していることを確認する必要があります。 おそらく、ART サポートが KitKat にバックポートされる可能性がありますが、優先度は低くなります。
あなたの働きにどう感謝したらいいでしょうか？
多くの人が数ドルを寄付する方法を求めてきたので、 寄付 今のページ。
機能 X または機能 Y を実現するモジュールを追加するには、いくら寄付する必要がありますか?
それは寄付ではなく、将来の仕事を期待して誰かにお金を払うことです。 フリーランサーの仕事には興味がありません。