I'm creating an app with 3 different languages. Every language contains a separate audio file (8 mb each).
Is it possible to split/export the project to 3 different .apk files prior to release on Market? I really do not want to put everything in one .apk due to the 24+ mb file size.
I can see a few options...
Manually build each one, release them as separate products in the Market in each language, e.g. "MyApp English", "MyApp Francais" etc. You could limit which countries see each one, to reduce confusion.
Same as above, but use Ant to automate the Android build process, so you can have one project for the app, but easily build a version in any language. Ant is quite involved, but I'd that in about a day you could learn enough to get an Ant build script running for your project. Android has built-in command line tools to help, so it'll create an initial Ant script for you (look at the "android" command line tool).
Create a single app, and when it starts, ask the user to confirm the language they want, and then start the download. Ideally you'd download a little bit initially to allow the app to work, and download the rest in the background so they don't have to wait. 8MB is quite a lot of data, so beware people will data expensive data plans so I think it is polite to always ask their permission for the download.
If it were me I'd probably lean towards the last option as it's simpler to build one app, and with sucha big download, the user needs to be in control of the process. Bear in mind many people wouldn't download an 8MB app if they knew beforehand it is that big.
Related
I want to migrate my android app (~40 MB of the base apk) that uses an .obb file (~70 MB) to the Android App Bundle format. I know for sure that the resources inside the .obb file will be updated less frequently than the base part. Therefore, there is no need for the users to download a full app (40 + 70 = 110 MB) on each app update but only the changed part (~40 MB).
What can I use after the migration to provide the same experience (update only changed part) to the end users?
Ideally, these unchanged resources should be accessible through the AssetManager like they are located within the assets directory.
For now, I found the Play Asset Delivery feature that allows moving some resources to a separate module to deliver it to devices at different times (install time / right after the download / when needed).
I've implemented an install time module logic and tested it via the internal + alpha tests. Throughout the testing, I found out each app update forces Google Play to download the full app (~110 MB) instead of the changed part (~40 MB). I do not know whether this situation will change when I release an app to the "available for everyone" track and I could not find the information about it either. Therefore, the answer "an install time module will not be redownloaded if unchanged; here is the documentation describing this: <link>" is fully acceptable and is one of the most welcoming ones.
tldr; Yes, in production, the download size will be smaller.
When you publish an app to production (whether APK or App Bundle), Play will generate patches of your app between this version and the previous versions of your app, so that your users only download the difference between the two versions. The consequence is that if you don't modify the content of a dynamic module, users will still receive updates for the unchanged modules but the download size will be very small.
Note that in practice, it is possible that the first couple of users downloading the update may still get the full size.
I have an Android project with 3000 photo's that needs to be available offline. When I include all the photo's in the build, the build fails. When I remove some of them, the build succeeds.
I have put the photo's in two dynamic modules that download at install time.
Here is the gradle scan for reference: https://scans.gradle.com/s/nn6eo527qvge6
Is this purely a size issue and if so, how do I get around that?
Is this purely a size issue
Probably.
how do I get around that?
Start by moving your photos out of res/drawable-xxhdpi-v4/ and into assets/ and adjust your code that consumes the photos to match.
Then, see what the resulting APK size is and compare it with the size limits for your intended app distribution channel (e.g., 100MB limit for the Play Store). If you exceed that limit, you will need to work through alternative approaches (e.g., APK expansion files).
To expand on CommonsWare's answer, I think the way you should do this is not by using Dynamic Modules but by using asset delivery. It's kinda "marketed" as a "for games" thing, but it's not limited at all by that.
The idea behind asset-delivery is that you have a pack of assets (images in your case) that you need for your app to function.
This "pack" of assets can be requested at install time, or later "on demand". All this is confusing because Dynamic Delivery sounds very similar. However, as stated at the top of the asset-delivery page, they use Different APIs.
In all honestly, I haven't used Asset Delivery, so take it with a grain of salt, and keep the considerations at hand, for example (and I quote):
If the download is larger than 150 MB and the user is not on Wi-Fi, the download does not start until the user explicitly gives their consent to proceed with the download using a mobile data connection. Similarly, if the download is large and the user loses Wi-Fi, the download is paused and explicit consent is required to proceed using a mobile data connection.
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 created a new project in Android Studio and nothing more (by that I mean having a main activity which does nothing). But when I checked the size of a project folder on my disc I saw it tooks over 40MB! I looked into the project file's content and I saw there folders for which I have questions about:
1) What is the purpose of folder (and it's content) MyProgram/build/generated? Is there a possibility to not create it? (I would save 30MB on my disc by deleting it.)
2) I presume that I shouldn't delete MyProgram/app/build/intermediates so I'm wondering if it'll grow with development of MyProgram? And if the answer is "yes" then how much the size will change? (It tooks almost 10MB now and I'm afraid what will happen when I do something more in my code.)
What is the purpose of folder (and it's content) MyProgram/build/generated?
For a module (e.g., app/) build/generated/ contains Java source code and other files that are generated as part of the build process.
If you are referring to the build/generated/ that appears off of the project root directory, that contains... a JAR. This is an odd place for the build tools to put this particular type of file.
Is there a possibility to not create it?
I don't think so. However, its contents will not go into your APK file. If your development machine is so short on disk space that a 30MB file makes a difference, you will have a very difficult time doing Android development.
I'm wondering if it'll grow with development of MyProgram?
Most likely.
how much the size will change?
That will vary by the size of your app (your code, third-party libraries that you add, etc.) and changes to the build tools over time. It is impossible to tell you exactly how large it will get.
The size from the basic "Hello world" is the minium, doesnt matter if the size is 30 mb or more, is just about the development code, when you generate de APK to share and install your app the basic "Hello world" the size is 2.5 - 3.5 mb. depends from the version of android studio are you using actually, the last version form android studio add somethings.
How i say the real size from you apk is the important, for example if you create the drawables resources for the diferents densities when you install the app just keep 1 density resources, an application size average 7 - 10 mb. A simple app is weird is the size exceeds this numbers.
1) build/ directory and build/intermediates/ is output of the build process,contains Java source code, do not delete.
2) repeat the 1) answer, do not delete.
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