たくさんの自由帳
Androidのお話
たくさんの自由帳
投稿日 : | 0 日前
文字数(だいたい) : 6760
どうもこんにちは、
モックし忘れたテストコードをGitHub Actions
で動かした結果、固まって4時間動いてたので流石に止めました。いつもは数分。
あぶね~従量課金だったら泣いてた。
4G/5G キャリアアグリゲーション
とEN-DC アンカーバンド
情報を表示するアプリをオープンテスト版に公開しています、
期待通りに動けばこうなります。
年末 2023 まとめの記事
で一瞬触れたあれです。
この時点で既にキャリアアグリゲーションに関連するAPI
を突き止めていて、、、ただこれは維持するのが厳しいなあって、代替案を探していた頃です。
オープンテスト版があるってことはギリギリ許容できる代替案があったという事ですね(自分で言うのか・・・)
NewRadioSupporter
のオープンテスト版のをダウンロードしてみてください。
多分一部の端末でしか動かないのでとりあえずはオープンテスト版として公開しました。誰でも参加できるはずです。
が、が、が
端末によっては動きません。し、動いた所で正しい情報が表示されているかも怪しいです。
割に合わないと思います。転用5G / sub6 / mmWave
の判定やNSA/SA
の判定ができれば良い場合は何もしなくて良いと思います。
オープンテスト版をインストールしたら、パソコンを用意してADB
コマンドを利用できる環境を揃えてください。
これは、普通のサードパーティアプリでは4G/5G キャリアアグリゲーション
情報にはアクセス出来ないため、特殊な権限を利用します。
これにはADB
コマンドを入力しないと付与できないためです(普通にダイアログで許可するとかではない)。。
これが打ち込むべきコマンドです。NewRadioSupporter
(アプリケーションID)へ、READ_LOGS
権限を付与(grant
)しろ。というコマンドになります。
adb shell pm grant io.github.takusan23.newradiosupporter android.permission.READ_LOGS
コマンドを入力した後、アプリを起動すると、「デバイスログへのアクセスを許可しますか?」と聞かれるので「一回限りのアクセスを許可」を選んでください。
これで、冒頭の通り、端末が対応していれば表示されるかもしれません。
ADB コマンド
を実行できる環境がない場合は、MuntashirAkon/AppManager
のアプリ(ADB モード
かワイヤレスデバッグ
)や、aShell You
(Shizuku
)を使えばパソコンなしでも権限を付与できるかもしれません。
どうやら5G
でもキャリアアグリゲーション出来るらしい。複数の5G
のバンドに接続するとかそういう話らしい?cellmapper
のsubreddit
とかを見ている限り確かに、n257
が複数見えてるスクショがある。
どうにかroot 無し
環境下で見れないか調べていたところ、*#*#4636#*#*
した時の画面の物理チャンネル構成
に表示されている情報が、4G/5G キャリアアグリゲーション
情報っぽいところまで突き止めました。
他にも関連しそうなAPI
があるのですが、
信頼度がなかったり(CellInfo#getCellConnectionStatus
)(これを正しく実装してない会社あり)、
欲しい情報がなかったりで(ServiceInfo#getBandwidths
)(帯域幅でバンドが取れない)
ちなみに今のオープンテスト版ではこれを無理やり取得してます。
だからよくわからないADB コマンド
を叩く必要があったのです。
物理チャンネル構成の表示に使われているのが、PhysicalChannelConfig API
ですが、これは正攻法では取得できません。
なぜならプリインストールアプリ限定権限で保護されているからです。サードパーティアプリでは利用できません。
ただAPI
が隠されているだけならまだしも、権限で保護されてると厳しいです。
サードパーティでも取得できる手段、探した限り2つありそう。
ただ、どっちも険しい道。 代替案があるだけマシ、、、
PhysicalChannelConfig
、どうにか抜け道がないかCode Search
でAOSP
を読んでいたところ、取得したらLogcat
に流している(出力している)ことを見つけました。
普通のLogcat
ではなく、無線に関係するlogcat -b radio
の方です!!
Logcat
に流してるから何だよという話ですが、
Logcatを読み取る権限はサードパーティアプリでも ADB コマンドを使えば付与することが出来ます。
これです。
<uses-permission android:name="android.permission.READ_LOGS" />
冒頭のようなADB コマンド
を叩けば、サードパーティアプリでもLogcat
を取得することが出来るので、PhysicalChannelConfig
の結果が流れてくるのを待ち受けることが出来るようになったわけです。
今のオープンテスト版ではこれを採用しています。メリットとしては。
ADB コマンド
を一度打ち込めば良いlogcat
読み出すのはexec()
すればいいデメリットとしては
AI
に聞けばなんとかなるGitHub - RikkaApps/Shizuku: Using system APIs directly with adb/root privileges from normal apps through a Java process started with app_process.
Using system APIs directly with adb/root privileges from normal apps through a Java process started with app_process. - RikkaApps/Shizuku
https://github.com/RikkaApps/Shizuku
Shizuku
という一部のプリインストールアプリ権限で保護されている API を代わりに叩いてくれるアプリがあります。
どういうことかというと、adb
コマンドって結構いろんな事が出来るわけですが。
有名どころではプリインストールアプリの無効化なんてサードパーティでは出来ませんが、adb
コマンドを叩けば出来ます。
冒頭で話した特殊な権限の有効化だってadb
なら出来る場合があります。
Shizuku
はこのadb
にある強力な権限をアプリ開発者にもたらしてくれました。
どういう事かというと、adb
が代わりにAPI
を叩いてくれます。先述の通りadb
コマンドには強力な権限があるため、
プリインストールアプリ限定のAPI
をサードパーティアプリから(adb
を経由することで)叩くことが出来ます。
adb
に付与されている権限はこれです。android/data
だってShizuku
を経由すれば見ることが出来るし、
中華スマホとかを追いかけている方ならワンちゃん知ってるかもですが、root 無し
でVoLTE
有効化するアプリも、このShizuku
を使っています。
(というかサードパーティじゃそんな事できんやろって思って見てたらShizuku
知った)
Shizuku
を使ってPhysicalChannelConfig
を取得してみるアプリも試しに作ったり(ソースコードからビルドする必要がありますが)GitHub - takusan23/ThirdpartyPhysicalChannelConfig
Contribute to takusan23/ThirdpartyPhysicalChannelConfig development by creating an account on GitHub.
https://github.com/takusan23/ThirdpartyPhysicalChannelConfig
このメリットですが、
デメリットとしては
Shizuku
を再度有効化しないといけないただ、開発的に前者のほうが良いかなあって、(プリインストールアプリ API を叩けるのに文句を言うなという話ではあるのですが)
AOSP
と同じようにAPI
を叩く必要があります。AOSP
のコードを読む必要があるということです。GitHub - RikkaApps/Shizuku-API: The API and the developer guide for Shizuku and Sui.
The API and the developer guide for Shizuku and Sui. - RikkaApps/Shizuku-API
https://github.com/RikkaApps/Shizuku-API
README
にもありますが、getSystemService()
で取得したManager
にある関数呼び出しをShizuku
経由にしたい場合、その関数の中身のコードを読んで、Shizuku
を使うように作る必要があります。Shizuku
を経由したAndroid API
呼び出しはこんな感じになります。
これらは電波関連の API
ですが、本来であればTelephonyManager
が内部でよしなにやってくます。
が、呼び出しをShizuku
経由にするため、TelephonyManager
が代わりにやってくれた処理を、AOSP
を元に読み進める必要があります。README
の通りですね。
狙いの関数の中身を読んで、Service
を呼び出している部分をShizuku
のものに差し替える。
本来は内部でよしなにやってくれるので、このコードは隠し API
扱いです。よってAndroid Studio
からは見つけることが出来ません。
これが次の理由になります。
val telephony: ITelephony
get() = ITelephony.Stub.asInterface(
ShizukuBinderWrapper(ServiceManager.getService("phone"))
)
val telephonyRegistry: ITelephonyRegistry
get() = ITelephonyRegistry.Stub.asInterface(
ShizukuBinderWrapper(ServiceManager.getService("telephony.registry"))
)
val subscription: ISub
get() = ISub.Stub.asInterface(
ShizukuBinderWrapper(ServiceManager.getService("isub"))
)
次に、Android Studio
からダウンロードするandroid.jar
(Android SDK
)は、隠しAPI
が削除された状態になっています。
が、Shizuku
を利用して隠し API
を叩きたいので、隠し API
が残っているandroid.jar
に差し替える必要があります。
もしテストを、GitHub Actions
とかでやっている場合は、CI/CD 環境
のandroid.jar
も差し替える必要があり、とても大変。
android.jar
があるので、それに差し替えることで、隠し API
もAndroid Studio
のコード補完に表示されるようになります。GitHub - Reginer/aosp-android-jar: AOSP编译出的android.jar,sdk里面以前反射调用的方法,现在可以直接调用了。
AOSP编译出的android.jar,sdk里面以前反射调用的方法,现在可以直接调用了。. Contribute to Reginer/aosp-android-jar development by creating an account on GitHub.
https://github.com/Reginer/aosp-android-jar
最後、いくつかライブラリを入れる必要があります。隠し API
を叩くためのライブラリと、Shizuku API
ですね、これは特に言うこと無いです、文字通りです。
Android
は一部の隠し API
をリフレクションを使って叩こうとしても、メソッドが存在しない例外をスローするように対策されてしまいました。
確かにAOSP
には存在するのに、実行すると落ちてしまう。
Shizuku
は手間を掛けてもなおプリインストールアプリ権限が必要な API を叩くことが出来るので、やる価値はバッチリあります。夢がある話です。
いつかShizuku
を使ってアプリを作りたいですね。その時は記事にでも!
experimental
ブランチのこの辺、オープンテスト版なんで特にテストとかは書いてないです。NewRadioSupporter/app/src/main/java/io/github/takusan23/newradiosupporter/tool/LogcatPhysicalChannelConfig.kt at experimental · takusan23/NewRadioSupporter
Contribute to takusan23/NewRadioSupporter development by creating an account on GitHub.
https://github.com/takusan23/NewRadioSupporter/blob/experimental/app/src/main/java/io/github/takusan23/newradiosupporter/tool/LogcatPhysicalChannelConfig.kt
UI
も少し変わってます。eSIM / 物理 SIM
どっちなのか、が取得できるので表示できるようにしてみました。
これが採用版の下書き、Material 3
というか、リストの頭とおしりは角が丸くて、
リストの間というかセパレーターの角は控えめな丸にするやつ、やってみたかった。
あ、没 Figma デザイン案、置いておきます
なんでオープンテスト版から始めたかというと、READ_LOGS
権限をいきなり投入したら、GooglePlay
になにか言われるんじゃないかとか、怪しまれそうとか、で、
(全然動かない等で)不評ならさっさと撤退しようと思って。
手持ちの端末でもGoogle Pixel
ぐらいしか動いてなさそう雰囲気、、、
Sub6-CA
NR-DC
これなにが違うの...NSA/SA
の違いってこと?
ちなみにPhysicalChannelConfig API
をサードパーティアプリに開放してくれってIssue Tracker
に投げてみましたがダメでした。
ん~~~どうにかしてほしいなあ
年に1度(2回になるけど)のAndroid
アップデートのAPI 差分
を、ダメ元で開放されてないか更新の度に見る生活を続けますかね。