I have android application (single apk file) with code and ga lot of graphics, It takes a lot of space. I want to devide my huge application into two parts. The first is a source code and minor graphice (takes low space), the second part includes all other graphic. When user launches first application, it uses graphic from another application.
1) Is solution it possible?
2) If it is possible, how can I access from first apk to a resource file at SD card, whick stores in another zip/archive/jar/or apk?
Maybe you can provide your graphic as a Content Provider in one application and then read them in another application.
You can use Library Projects to achieve this.
There are a number of ways to do this. One of the more popular is to require the application to download the large graphics on "first-run". This is done by most large game apps.
Related
Is it possible to split my Android apk of 512MB into different parts or modules.
Compile small part of it into a release Apk (small Apk size) for Play Store.
Then fetch the remaining parts or modules from online or your own server during first time install on a device.
Thats:
Small Apk to Google Play Store
Fetch remaining big files after first install.
I am using Android Studio.
Of course you can, that can be easily achieved if you got to split heavy resources(like images, videos, databases). Here you must write some logic which will download that resources and will work with them after a successful download.
I cant imagine a situation when you must to split a code in a separate module, compiled code is light and dont increase apk size so much as another resources. Code can become heavy when there is a lot of code from libraries, in that case I suggest you to learn about Proguard Shrink.
Also you can learn why in android is not possible to load java modules in runtime. On of the reasons is performance given by JIT
Here a is workaround with ndk How do I import shared object libraries at runtime in Android?
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.
I'm just wondering how the following scenario can be solved:
I want to write a very simple app for my daughter. The app displays 4 colored fields on the activity and through speech output says something like "tap green". She should then tap the green field to get positive feedback. So far, so easy.
I then thought it might be nice if the app would also "grow" as she grows older. Maybe later I want to have a game mode where I display animals, numbers, vehicles, etc., so it would be nice if I could have something like "Shape sets" - basically a set of images along with a description of what the app should say for each image. Also easy enough - all you need is a set of images and an XML file describing the images.
BUT
I'd like to be able to install these "Shape sets" as additional APKs later on, so that I don't have to modify the app every time. I'd like to install the APKs, so that the contents are added to a specific sub folder on the SD card, into which my app looks to enumerate available "Shape sets".
If I ever published the app to the Play Store, other people should also be able to download the "Shape sets" I create (no need for user contributions, though).
Is that possible? If so, what would I have to do to have the Android OS "copy" the contents of an APK to a specific folder (lets say "/TapGame/Shape Sets/Animals") on the SD card? Or is there even another way of achieving what I want that I didn't think of?
The term "plugin architecture" just came to my mind as I wrote the question. Searching using that term I found this question: Extend my android app in different APK
It seems to provide a solution to my problem - I'll investigate this further, but please feel free to suggest other possible solutions!
Is that possible?
Um, sure.
If so, what would I have to do to have the Android OS "copy" the contents of an APK to a specific folder (lets say "/TapGame/Shape Sets/Animals") on the SD card?
Android won't do any of that. You have to do that. You would have to detect that a "shape set" APK was installed (either watching for package-installed broadcasts, scanning all installed apps for ones that seem to be a "shape set", etc.). Then you would have to arrange to copy whatever you wanted to wherever you wanted it, either by:
Asking the "shape set" app to do it (e.g., send a command to some IntentService), or
Using createPackageContext() and trying to do the copying from your main app
Or is there even another way of achieving what I want that I didn't think of?
Um, just use ZIP files that your app downloads itself from a well-known location. That corresponds to Dave Smith's final paragraph of his answer on the question you just linked to in your edit.
Or, just update the main app. I'm not quite certain what effort you think that you are saving otherwise.
Or, just keep the content online, using a Web service to indicate the available "shape sets" and downloading them as needed (with optional caching).
Fascinating question. If you really want to go for plug-ins then OSGi would probably be the way to go, but it's a lot of work to get to know and to use and seems like overkill in this case.
I don't know how your shapes are defined, but they are probably each defined in a separate file-set, providing the shape (maybe a png or jpg?) as well as the audio-file that will be used as a command for this shape. If the folder in which these file-sets are stored is fixed (TapGame/Shape Sets/...) the app could scan the folder each startup and the views could be generated accordingly (in this case, the activity cannot be build entirely in the XML-File, but must be partially done programmatically).
The Plugin-Aps would be rather easy. They are an apk which includes the file sets (jpg and mp3 or whatever). Started once they deposit all these files into the specified folder (they probably check before if these files exist) and then the apk can shut down again and be uninstalled.
on the next startup the Tap Game App would find the new symbols and include them into the game.
This seems rather straight forward to me. Another way would be to actually store the shapes and audio files on the internet and with each start of the App check if the number of shapes and audio-files has changed and create local copies of new ones. This would mean no downloads of apks... probably a more usual approach to the issue.
I am very interested to hear what you make of it, seems like a different approach then the norm, which is always cool to see.
I today released an Android application which includes some language-dependent MP3 files. My concern is that the more languages, the bigger the application size.
What would be your recommendation:
Release one application per language (not really easy to deal with, would have to release n apps each time I add new features to the software)
Provide a mechanism to download the MP3 files at first launch (would require an internet connection whereas the user may think he doesn't need one. It could bring frustration.)
Optimize the MP3 files (not that scalable if I have to support 10 languages)
[ ] fill the blank !
Hervé.
I'm a big fan of user-choice. As such, I might make the MP3 files optional, but on first run explain to the user that you have some language-dependant features and allow them to download them if they desire.
The reasons for this are many:
It keeps the file size low.
It is easily supportable with one distribution.
It allows you to extend/correct the language files independent of the software.
It is upfront, and gives the user the choice of language (even potentially multiple).
It allows the user to change the aural language without having to uninstall/reinstall or have duplicate installs.
There are many users (such as myself) who never speak to their phone, and never want to hear it speak to them. :) (Yes, I'm crazy)
Just a suggestion!
FuzzicalLogic
I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.
We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.
I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.