Androidの開発者認証を回避する理論的な方法について議論されているスレッド。GoogleがADBや開発者向け機能を制限する可能性や、それに対する代替手段、既存のShizukuなどのツールの将来性などが議論されている。
-
1：スレ主
Androidの開発者認証回避の理論的な方法ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ https://enaix.github.io
-
9：以下、名無しがお送りします
つまり、オールインワンアプリってこと？
-
12：以下、名無しがお送りします
Androidみたいなオープンなプラットフォームでこんなこと考えなきゃいけないとかマジありえん…
-
13：以下、名無しがお送りします
GoogleがローダーAPKをブロックしたら次どうすんの？
-
33：スレ主
>>13 アプリを修正/難読化して再アップロードするしかない 最善策じゃないし、俺も不満だけど、今のところadbに頼らない唯一の方法 adbが制限されるのが心配なんだよね（例えば、自分でビルドしたapkしか許可しないとか）
-
22：名無しのA
>>13 結局、そういう対策ってGoogleに「マルウェア」認定されたら終わりじゃん？ 応急処置じゃ根本解決にならんよ
-
23：以下、名無しがお送りします
>>22 それ言うなら、Shizukuが同じ扱いされる可能性は？
-
24：名無しのA
>>23 ありえる Google様が「マルウェア」と「危険」を決めちゃう時代
-
37：以下、名無しがお送りします
不安定すぎる回避策だわ メンテが地獄だし、最終的にはADB経由でインストールする必要が出てくる（Googleがこういうアプリをブロックした場合） それなら最初からADBで全部インストールするわ
-
46：名無しのB
>>37 素朴な疑問なんだけど、GoogleがADBをブロックする可能性は？ 開発者設定から有効にする必要があるし、Googleが制御できるんじゃない？
-
88：以下、名無しがお送りします
>>46 Googleがセキュリティと悪いニュースを本当に気にしていて、パワーユーザーを困らせることを考えてないなら、そうする理由はない 過去にはパワーユーザーを無視してきたけど、ただ困らせるためだけに何かした例は少ないと思う
-
94：以下、名無しがお送りします
>>46 GoogleがADBをブロックする可能性？ Android Studioは完全にADBに依存してる デバイスのフラッシュも ADBなしで開発中のアプリをデバイスにロードできない ADBなしでデバイスをフラッシュ/再フラッシュできない iOSからiTunesを取り上げるようなもの
-
51：以下、名無しがお送りします
>>46 開発者はテストする必要があるからね だから残されてるんだよ
-
72：以下、名無しがお送りします
>>51 重要なのは「開発者」ってこと 一般ユーザー向けにadbをブロックする理由がない
-
61：名無しのB
>>51 Appleみたいに開発アカウントに料金を課金するか、エミュレーターでテストさせるようにするんじゃない？
-
71：以下、名無しがお送りします
>>61 Appleはテストにお金かからないよ 払わなければ、自己署名アプリは1週間しか持たないけど（再インストール必要）
-
76：スレ主
>>46 技術的には、いくつかの方法で制限できる 自己署名apkのインストール数を制限したり、アンロック手順に何か仕掛けたり（別の人が指摘しているように） だから代替手段を探り始めたんだ
-
82：以下、名無しがお送りします
>>76 現実的には、信頼できない状態にするフラグを立てて、銀行アプリとかeSIMとか使えなくするだろうね だから、日常的に使う端末で開発者向けインストールはできない
-
99：以下、名無しがお送りします
ShizukuとInstall With Optionsが、スマホ単体で実行できる唯一の現実的な解決策 またはTermuxだけど、もっと面倒 ADBは影響を受けないと思うけど、開発者設定を有効にするのに開発者アカウントが必要になる日が来るかもしれないのが心配 様子見だね
-
104：以下、名無しがお送りします
>>99 アニメーション速度とか、すべてのBluetoothデバイスを表示するとか、開発者設定の半分くらいはメインの設定アプリに移動してほしいわ
-
114：以下、名無しがお送りします
GoogleはADBを使ってローカルにアプリをインストールできるようにすると言ってるけど、詳細は不明 どんな詳細が欲しいんだ？ 既にADBでインストールできるし、Googleが公式に推奨してる認証要件の回避策じゃん One UI 8のアップデートでサイドローディングが削除される リンク先のサイトはサイドローディングじゃなくて、ブートローダーのアンロックについて… ShizukuとInstall with Optionsを使え
-
120：スレ主
>>114 ユーザーがビルドしたAPKじゃなくて、外部からダウンロードしたAPKをインストールするプロセスに関する詳細 開発者テストのためだけに許可すると言ってるし、APK署名のインストール数で制限するかもしれない
-
127：以下、名無しがお送りします
>>114 Googleは制限するかもしれない 例えば、リモートADBはAPKをインストールできないとか ADBを使ってインストールしたAPKは、iOSみたいにローカルで署名してデバイスに紐付ける必要があるとか または、有効期限を設定して、7日ごとに新しいAPKをビルドしないと開けなくなるとか ローカル開発はできるけど、日常的なサイドローディングには実用的じゃない方法はたくさんある
-
128：名無しのA
>>127 制限するだろうね FAQから: 「APKを改造またはハックして自分のデバイスにインストールしたい場合、認証が必要ですか？」 FAQでは、開発者が自分のデバイスにインストールする場合についてのみ言及してる ADBを使って他の開発者のアプリをインストールすることについては何も言ってない
-
134：以下、名無しがお送りします
ADBは署名されていないアプリもインストールできるし、ShizukuはPCなしでオンデバイスでできる
-
137：以下、名無しがお送りします
じゃあGoogleはAndroidでWebブラウザも禁止するの？ セキュリティリスクがあるのはわかるけど PWAアプリのインストールはどうなる？ それも禁止するしかないよね？ セキュリティリスクがあるから 皮肉だよ
-
141：以下、名無しがお送りします
>>137 アイデアを与えるな
-
148：以下、名無しがお送りします
つまり、Android版の https://github.com みたいなもん？
-
152：以下、名無しがお送りします
ActivityManagerServiceがあるから無理だと思う 起動時にマニフェスト内のすべてのアクティビティを知る必要があるし、ユーザーアプリにはサービスに動的にアクティビティを登録する権限がない できることと言えば、このClassLoaderメカニズムを使って完全に新しいランタイムを作成し、Binder経由でシステムサービスに実装されているフレームワークAPIを実装すること このアプローチを試していくうちに、最終的にはそこにたどり着くと思う 検証されていないアプリをロードして、それらのアプリからのフレームワークAPI呼び出しを実際に機能させるシムを作成することはできない これは、FlutterやReactive Nativeのような独自のモバイルアプリケーションフレームワークを作成するレベルであり、開発者検証ポリシーを回避するためにGoogle Play Protectによるコード分析によってブロックされるリスクがある だから本当にリスクを冒す価値はないし、根本的な解決にはならない また、フレームワークがこのようなフレームワークAPIの再実装をブロックする方法はたくさんある 例えば、ClassLoader APIを制限するなど ネイティブコードでもうまくいかないと思う ネイティブコードは書き込み可能なディレクトリからロードできないからね（Termuxの件を参照）