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.
Related
I'm trying to get the Unity mobile Android APK build size to below 150mb, but it's currently at 170mb. I'm reading through many online docs, but can't find anything that so far reduced my build size. (For reference, I'm creating a "Virtual OS" where many virtual apps are bundled into one, and can be experienced in many different environments, so that increases size.)
My main question is, how can I find the biggest file size "offenders" in my project? Unity's doc tells me to look into the Editor Log's Build Report list, but the files mentioned in the top there (as "uncompressed", e.g. my 20k something PNG becomes a 1+mb file in that list), mainly textures, do not actually help when I next time remove them in another test build. Neither does it relevantly help when I change the Android texture setting to something more highly compressed (e.g. 1024 max Mitchell, which I had for most of my files anyway).
I've tried both APK building, as well as ABB, but both results are quite big. (Switching the API Compatibility Level from .NET 4x to 2 doesn't help either.) I'm compiling to 64bit architecture.
Edit: A first big improvement became removing an (unneeded for Android) Oculus directory (and accompanying Package Manager packages). But this wasn't shown in any charts.
Thanks for any pointers!
-- using a Linux Mint system with AndroidStudio 2.3.3 -
Even the simplest "HelloWorld" project under AndroidStudio fills the projectdirectory with 1000+ of files ??
Is there a way to avoid this or bring back the number of files to a reasonable quantity ?
( I remember when working with eclipse for Android the same simple project generated a 20+ number of files ? )
Thanks for any advice or explantion.
erics
Even the simplest "HelloWorld" project under AndroidStudio fills the projectdirectory with 1000+ of files ??
That isn't the simplest one. I just created one with 125 files in app/build/, which my guess is the source of your complaints.
The project started with ~1100 files in app/build/. Most of the ~1000-file difference between the starting point and ending point were from dependencies, particularly appcompat-v7.
Is there a way to avoid this or bring back the number of files to a reasonable quantity ?
Of all the metrics to be concerned about, the number of files in app/build/ should be a very low-priority one. But, you are certainly welcome to remove dependencies from your builds to try to reduce the number of files.
I have one requirement to compress APK size based on type of device(LDPI, MDPI, HDPI.., etc). My client is demanding to give multiple APK's. According to his statement Small devices having low configuration so the apk size should be less, and MDPI is bit better than LDPI so the size may going to increase. So he is demanding to give the build accordingly. So that user will download the app with in less time and saves the internal/ External memory.
For that I tried lot of ways to compress the APK, but I failed at every aspect:
*9- Patch : My project does not contains all the images are 9-Patches, in fact 90% of images are non-9patch's.
*Pro-guard: I tried to reduce the file size using Proguard, but as far as I know proguard is for protecting the my code, and apk size is not much compressed.
* And I tried out not working out for me.
Right now I am following the bellow process, I know this is very bad procedure:
Generating the APK for LDPI devices I kept all resource files in res/ldpi folder only, I am following with same procedure for MDPI, HDPI, XHDPI Etc.,
By using current process, I'm wasting lot of time and it is very bad process also I guess.
To solve the above problem can you please help me out.
Use Gradle for Android and its support for APK density splits. Gradle for Android can then generate APK files for each density, plus an optional "fat APK" containing all densities. You can either use Android Studio as your IDE, or set up a build.gradle file that can build an existing project in the Eclipse/Ant classic directory structure.
However, your client needs to understand that not all distribution channels support distributing different APK files by screen density. The Play Store does. I do not know about other channels (e.g., Amazon AppStore for Android). And the user probably has no idea what the density of their device is, so relying upon the user to choose one of several versions to download from a Web site is unlikely to be reliable.
Inform your client that for all devices apk size will remain same. Make him/her understand that On play store you do not upload different apk's for different types of devices.
With the fantastic help of Tim on this thread Controlling Android app with bluetooth mouse/ presenter I added bluetooth remote control of my application. After finishing this, I noticed my apk file went from 175k all the way to 1711k - 10 times larger! I have implemented the bluetooth changes on a test application without seeing any change in file size so I am not sure what caused this. I did have some kind of Eclipse problem in the middle of this and had to do a rebuild to get the source to run again so maybe that had something to do with it.
Searching for file size change here and on Google gives me questions of people who want to make larger files to hold more stuff, not my question. I can't seem to find relevant answers.
The application has no graphics, pdf's, or other files of any size at all. It just reads some GPS stuff, does some math, and displays the results as text.
Is there some way to get the file size back down? Is there an Eclipse option? This is my first real (non test) application and it is finished and working but I am concerned with the file size increase.
You can check the contents of apk file easily. An apk file is simply a zip file with different extension. Just replace .apk with .zip and unzip it. Then diff the contents with your previous .apk file and find out what file makes the difference.
I encountered a similar problem with the APK size. One way to check out which resources are the culprits is to 'Open Editor Log' in Console.
Some helpful explanations can be found here:
Unity build project game 2d to apk with huge size because textures
https://docs.unity3d.com/432/Documentation/Manual/ReducingFilesize.html
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.