I want to create an "app loader" (primary) application, which will fetch a license from a server -- this license in turn will determine the features available in two other (secondary) applications.
I'd like to know the best approach to this. Should I:
just fetch the two secondary apks from the same server as the licensing info and attempt their installation from within the app loader code;
pack the secondary apks into the primary app apk. Am I able to then install the secondary apks from within the 'parent' apk's resource/assets at runtime?
recreate the secondary applications as multiple activities within one parent app -- with multiple launchers?
I require advice on the individual scenarios' feasibility, a preference (with a reason why) and indeed which ones are actually possible.
Many thanks.
Am I able to then install the secondary apks from within the 'parent' apk's resource/assets at runtime?
Not without copying those files to external storage. Since you cannot modify resources or assets at runtime, your "packed" "secondary" APKs will remain in the parent APK, for better or worse.
I require advice on the individual scenarios' feasibility
All are feasible, within the constraints outlined above.
Related
Is there a reliable way to specify the UID that Android assigns to the APK during the AOSP builds?
If there is a system APK that is built into and Android image, we observe that sometimes the UID associated with that APK ends up different between consecutive image builds. There seems to be little information that explains how exactly are the UIDs assigned.
The reason we'd like to preserve the UID, for at least one of the applications, is because an application needs to write to an internal file system areas, and if the UID changes between builds, then after a newer image is installed on a device, the files written by the older application are no longer accessible (the permissions to these files are 0600).
We now know that there is a "sharedUserId" Manifest statement that we can probably use for this, but since the application is already in the field, it's too late to apply that, plus that attribute has been deprecated in 29.
We have a suite of applications that depend on the sharing of a directory/files on external storage.
I've currently opted out of the Android 10 OS changes to scoping (requestLegacyExternalStorage), but this is going away and I've spent many hours trying to find a solution for simply sharing files between applications.
The only solutions that I see offered are:
SAF - which appears to make the user choose through UI. This is completely undesirable.
Use a File Content Provider - the way I understand this, I would have to make the user install an apk with my provider in it before installing any of my applications. Forcing the user to install two apks to run one application is very undesirable. (Yes, they could both be in one apk manifest but who knows which of my suite they will want to install)
Media Store - My understanding is that this also forces the user to pick something he should have no knowledge of - and is really intended for audio, video, image and downloaded directory.
Am I missing a solution for these simple requirements?
Am I missing a solution for these simple requirements?
There is no simple solution. You would basically need to have each app have its own copy of the shared data (to deal with potential uninstalls) and have some sort of synchronization protocol so each app in the suite can inform others about changes to their copy of the data.
Using SAF is the simplest approach for your scenario. Or, move the data off the device into "the cloud".
My understanding is that this also forces the user to pick something he should have no knowledge of
It is the user's device. It is the user's storage. If you put files in a user-visible location on the user's storage, they are the user's files. Your apps are merely one set of tools for working with those files, nothing more.
I am working on application with multiple types choices and every type has different UI, content and operations.
If i packaged all activities, xml and drawables files inside same .apk file for all users with showing and hiding methodology it's an inefficient way as it waste user space and download time.
Are there another ways to upload activities,xml and drawables files to external servers and download them based on user selected choice?
appreciated any help.
thanks.
You may download the Activities and other Java classes from the server and load them up, perhaps even Drawables, but XML part would be a tricky one.
If you can manage to avoid XMLs by creating layouts with Java if Layout is what you meant by XML, the answer is yes, it is possible.
You will need to explore how to load Java classes at runtime.
the answer is here
Multiple APK Support
-----> The build system enables you to automatically build different APKs
that each contain only the code and resources needed for a specific
screen density or Application Binary Interface (ABI). For more
information see Build Multiple APKs.
We have an Android project where we maintain a single code base for different customers, what will be the fastest/most efficient way to compile for different customers every time? Few options I found and my questions:
writing scripts: to replace resources folder and edit app name, version, etc.
Using Android Library Projects It is gonna be quite impractical to separate current project as Library projects, I am thinking whether it is possible to save some settings and resources files as a Library project and just import different library projects for different compilation?
Storing settings and resources on a remote server Is it possible to store resource files and some app settings (xml, constants, etc) on a remote server, and download them and replace to the app when the user first launch the apk? Where will these files be stored?
Any other options you would suggest?
Android Studio provides a feature called "flavors" that allow you to quickly define different configurations from a single code base. I have just learned about this in the last couple of days, so I don't know a lot more than this.
The best way I've found is a post build script step. Use a default set of resources/assets for your main build. This is your default apk, use it for default testing. Save the unsigned apk this builds. Then for the customer specific APKs, open up the unsigned apk (its just a zip file), overwrite any overwritten files, then sign the new version.
This works fine so long as you don't need to change code for different customers. It also doesn't put any unneeded assets/resources in any build, so you don't leak info to one customer about your other customers by including their files.
If you do need to change code, the best way is to do a runtime check on a variable from a settings file. And overwrite the settings file the same way you do everything else.
As an added bonus, if you need to you can write a very fancy system that would allow the customer to upload his own files to override your defaults (including allowing them to override some of your settings), so you don't need to deal with a dozen change requests. That requires a lot more work though.
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!
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.