私は、必要に応じて専用サーバーからサードパーティのapk(つまり外部apk)をダウンロードすることができるアプリケーション(つまりbase apk)を開発中です。これが起こると、ベースアプリケーション(ベースapk)は、先にダウンロードされた各apk(すなわち、外部apk)を、hereと同様の方法でインスタンス化し始める。サードパーティのapkがローカルリソース(すなわち、res/layout/Layoutファイル)を利用するように設計されている場合を除いて、プロセス全体がスムーズに流れます。そのような場合、これらのローカルリソースにアクセスするために使用されるサードパーティのapkのコード(たとえば、以下に示すようにレイアウトを拡張しようとするなど)によって、NULLPointerExceptionがスローされませんでした(それぞれを見つけることができません)。外部から読み込まれたapkにあるレイアウト固有のリソースにアクセスするには?
これは実現可能なシナリオかどうか疑問です。もしそうなら(おそらく私が推測している)、現在の私は却下したストレートな解決策/回避策がありますか?
LayoutInflater.from(this.getContext()).inflate(mypackage.external.apk.R.layout_to_be_loaded, this);
ありがとうございます!
ご連絡ありがとうございます。 私が聞いていたものではありません。:) はい、確かに、プロセス全体がハッキングを構成しています。それが概念証明アプリケーションではない場合(これは私の電話よりも多くの電話機にインストールされません)それは選択ではないでしょう。 第三者のローカルリソースに直接アクセスできないメインAPではなく、サードパーティのAPKそれは自己です。 外部クラスをロードすることはある程度可能ですが(たとえそれが重大なセキュリティ制約を課しても)、ローカルリソースはロードできません。 – George
@George: "しかし、少なくとも3番目のパートのローカルリソースに直接アクセスすることはできないが、第三者のAPKは自己であるため)、サードパーティ製のAPKは厳密には存在しないからです。使用しているAPK拡張子を持つZIPファイルがあります。それはインストールされたアプリではありません。 – CommonsWare
@George:「ある程度、外部クラスを読み込むことはできますが、ローカルリソースはありません」 - EXEをインストールする代わりにランダムなx86命令をEXEから取り出してRAMに読み込むようなものです。 EXEには、インストール時に解凍される他のものが含まれていることがあります。アプリはそれがそこにあると想定しますが、スクリプトキディのアプローチはそれをバイパスします。 – CommonsWare