最近、多くのvivo/iQOOユーザーが、ADBに依存している多くのモジュールが、文字、最適化ツール突然、「動かない」と言われます。

表面的には、モジュールの破損かコマンド実行の失敗のように見えます。 しかし現実はもっと複雑で、多くのコマンドは一見正常に実行されますが、実際にはシステムはもはやこれらの修正を受け入れていません。

ここでは、現在直面しているいくつかの重要な課題について簡単に説明します。
設定、入れた構文は基本的に無効になっています
以前は、多くのADBモジュールがシステム設定テーブルを修正するために以下のコマンドを使用していました:
settings put system xxx xxx
settings put secure xxx xxx
settings put global xxx xxx
この方法はかつて非常に有用で、高速な実行、簡単な互換性、そして多くのSetEditエントリをこのように書くことができました。

しかし今、vivoのシステムには明らかな制限があります:
settings put …
コマンドラインは誤りがないように見え、「実行成功」という印象を与えることもあります。
しかし問題は、システムがこの書き込みを単純に無視してしまう可能性があることです。

つまり、これは従来の失敗ではなく、エラーを返したり権限が不十分であることを示すわけではなく、表面的に実行され、実際の値がシステムに採用されていないということです。

これが多くのモジュールが登場している理由でもあります。

脚本は完成した
このソフトウェアは成功を促しました
ADBは明らかな誤りを報告していません
しかし、機能自体は全く変わっていません

根本的な理由は、設定がもはや信頼できなくなっていることです。
setpropは普通のADB権限で軽く使えるものではありません

また、合格を目指すモジュールも存在します:

setprop xxx xxx

システムプロパティを変更するために。
しかし、この解決策の問題点も明白です。多くの小道具はシステムレベルの権限を必要とします

通常のADBシェル権限は同じではありません rootそして、これはシステム特権と等しくはありません。
したがって、システム挙動、デバッグスイッチ、ベンダープロパティに関わる一部のsetpropは、通常のADBによって実際に変更が許可されていません。

一時的に書く属性もあれば、直接却下されるもの、ターゲットロジックに影響を与えないものもあります。 特にベンダーシステムがますます厳しくなる中で、通常のADBに頼ってシステム属性を変更するのは基本的に安定した解決策ではありません。

簡単に言えば:
adbシェルはシェルのユーザー権限のみを獲得し、ユニバーサル権限は得られません。 setpropが動作するかどうかは、特定のプロパティ、SELinuxのポリシー、システム権限、ベンダーの制限によって異なります。
設定を回避するには、コンテンツプロバイダーに行けます

SetEdit関連のテーブルを期限切れの「settings put」に頼らずに修正することが目的であれば、現時点で最も現実的な方法はContent Provider構文を用いて動作することです。

大まかにこんな感じの考え方です:
content insert
content update
content query

つまり、カプセル化のために設定層を使わず、システムの公開されたプロバイダーインターフェースを通じて対応するデータを直接操作するということです。

この方法は「設定設定」よりも根本的であり、いくつかのシナリオでは無視されがちな「設定設定を置く」問題を回避できます。

しかし、明らかな欠点もあります。それは遅さです

特に、複数のSetEditエントリをバッチで書く場合、各項目が1つずつ実行されている場合:
content update
content update
content update

速度は非常に遅くなり、ユーザー体験も明らかに悪化します。

ソフトウェア開発者は複数のシェルスレッドを使うことで高速化できます
手動で動かす普通のユーザーなら、少し遅くても我慢するしかありません。
でも、もしツールタイプのソフトウェア、ADBモジュールマネージャー、自動化などなら、構成また、開発者は単一のスレッド内で大量の「コンテンツ」コマンドを一つずつ実行するのをやめることが推奨されます。
複数のシェルスレッドを使って同時に実行することも検討できます。例えば:
複数の「adbシェル」セッションは異なる設定項目を並行処理し、それらをグループ化してスレッドごとに書き込むことで、各コマンドごとに別々にシェルを起動するコストを削減し、コマンドが成功裏に戻ったかどうかを確認するだけでなく実行結果の検証も行います
これによりバッチ書き込み速度が大幅に向上します。
ただし、同時スレッドも適切に管理すべきです。無意味に数十、あるいは数百スレッドを同時に動かすことは推奨されません。
スレッドが多すぎると、実際にはシステムに悪影響を及ぼす可能性がありますラグ命令の妨害や、異常な提供者の反応まで。

より合理的な方法は、例えば4〜8シェルスレッドのスレッドプールを構築し、デバイスのパフォーマンスに応じて動的に調整することです。

ここで、「成功」を判断するのはコマンドの返り値だけではなりません
これが現在最も一般的な落とし穴です。
以前は、多くのモジュールで成功を確認する簡単な方法がありました:sh
settings put xxx
コマンドが正しければ成功とみなされます。
しかし今や、そのような判断だけでは十分ではありません。
より安全なアプローチは以下の通りです:

1. ターゲット値を書く
2. 現在の値を再度読み上げる
3. 変更が本物かどうかを比較する
4. 必要に応じて書き込みメソッドをやり直すか切り替え
例えば:
settings get global xxx
content query …

値の読み戻しが本当に期待通りである場合にのみ、修正は成功とみなされます。 そうでなければ、ソフトウェアは「有効」と表示されていても、実際にはシステム自体が起動していないことがあります。
現在、vivo/iQOOの多くのADBモジュールが故障していますが、これは必ずしも作者コードの誤りによるものではなく、システムが関連インターフェースの制限を強化したことが原因です。
現在、大まかに次のようにまとめることができます。
「settings put」:成功しているように見えますが、実際にはシステムに無視される可能性があります
「setprop」:多くのプロジェクトはシステム権限やルート権限を必要とし、通常のADBでは処理できません
「コンテンツプロバイダー」:現在は比較的実現可能ですが、実行速度は遅いです
バッチ書き込み:速度向上のために複数のシェルスレッドを使用することが推奨されます
成功チェック:検証を読み返す必要があります。コマンドにエラーがあるかどうかだけ確認することはできません
したがって、今後もこれらのツールをVivoに適応させたいなら、コアアプローチは「直接設定を出す」から「提供者書き込み+結果検証+並行最適化」へと移行すべきです。
これは個々のモジュールの問題ではなく、システムポリシーの変更後に古い解決策が全体的に不安定になることです。

開発者で、あまり多くのコンテンツ構文を書きたくない場合は、kbatteryを使うことができます。新しいバージョンでは、kbatteryが設定を変換し、構文を入力できます
以下はいくつかのおすすめです:
9 削除 92⛰️9 削除 2 削除 26⛰️45
関連する開発者が実装を迅速に調整できることを願っていますし、一般のユーザーがモジュールの失敗を見てすぐに著者が諦めていると思わないことを願っています。 多くの場合、コマンドが実行されないのではなく、システムがこの方法を認識しなくなったのです。