0

I am in the process of developing an application (i.e.: base apk) which is capable downloading, when the need raises, third party apks(i.e.: external apks) from a dedicated server. When that happens the base application (base apk) begins to instantiate each previously downloaded apk (i.e.: external apks) in a way similar to that elaborated here. The whole process flows smoothly except in cases where those third party apks are designed so as to take advantage of local to themselves resources (i.e.: res/layout/Layout files). In such cases 3rd party apk's code used to access those local resources (e.g.: by trying to inflate a layout as shown below) fails throwing a NULLPointerException(being unable to locate each of them).

I wonder whether or not this is a feasible scenario. If yes (most probably I guess) is there any straight forward solution/work-around that currently I dismiss..?

LayoutInflater.from(this.getContext()).inflate(mypackage.external.apk.R.layout_to_be_loaded, this);

Thank you!

Community
  • 1
  • 1
George
  • 3
  • 1

1 Answers1

0

When that happens the base application (base apk) begins to instantiate each previously downloaded apk (i.e.: external apks) in a way similar to that elaborated here.

Which is insecure, offering the possibility of a code-injection attack. I would not touch that technique with a ten-foot pole.

is there any straight forward solution/work-around that currently I dismiss..?

Not really. You are ripping the bytecode out of a foreign non-installed APK and executing it in your process. You have no way to somehow rip out the resources as well and get them blended in with yours.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thank you for your prompt reply! Not really what I was hopping to hear... :) Yes indeed, the whole process constitutes a hack.. If it wasn't about a proof of concept application (which is not going to be installed in more phones than mine) it wouldn't be a choice.. Though, it doesn't make a lot of sense (at least at glance), since its not the main apk that cannot directly access third partys' local resources, but the third party apk it self.. It is to some extent oxymoron being able to load external classes (even if that poses significant security constraints) but not their local resources.. – George Mar 10 '12 at 09:04
  • @George: "Though, it doesn't make a lot of sense (at least at glance), since its not the main apk that cannot directly access third partys' local resources, but the third party apk it self" -- there is no third-party APK, strictly speaking. There is a ZIP file with an APK extension that you happen to be using. It's not an installed app. – CommonsWare Mar 10 '12 at 12:16
  • @George: "It is to some extent oxymoron being able to load external classes... but not their local resources" -- it's like grabbing random x86 instructions out of an EXE and poking them into RAM instead of installing the EXE. EXEs often contain other stuff, to be unpacked upon install, which the app assumes will be there, but your script-kiddie approach bypasses that. – CommonsWare Mar 10 '12 at 12:16
  • @ CommonsWare: Yes, I get your point.. I was merely betting on the fact that all resources were already in the appropriate format (i.e.: properly compiled), which seems to be not enough.. But such is life/code..! :) – George Mar 10 '12 at 15:26