I'm trying out cocos2d-js (version 3.0) and even the simplest 'Hello World' project is over 1 gigabyte in size when it is created.
Is this normal? (I have a habit of creating dozens of demo-projects when trying out a new platform, but it looks like I need to get myself a bigger SSD, just for this!)
Also, the size of the apk, when compiled for Android, is about 9 MB. Any ways to reduce this size?
Sadly, yes. I've mentioned this in the community a couple of times to no avail. I believe this files should be referenced/cached in a common location for all projects, but the dev team seems to have other priorities at present.
If you wish to keep your projects you'll be better off heading to their frameworks directory and deleting all folders except cocos2d-html5 (this one should be 5MB only) in there. -
An alternative would be to also delete the cocos2d-html5 folder, place it in a common dir (or use the copy in your install folder) and reference the path properly in your projetc's config file. Keep in mind this option may break code suggesstion/autocomplete in some editors, and throw errors in your webserver when you try to run the project.-
This way, you'll be able to run any of those projects in the browser, and then only add the files neccessary for native compilation in projects you wish to test in the emulator or your device (or compile for publishing). This will sadly take a lot of time to copy and re-generate the files, of course.
As for reducing the size of the .apks... I don't know a way. I know efforts are being made to optimize the binder, and there may be a way to explicitly avoid packaging unused stuff, but I don't know about it.
You can reduce the app size in Cocos2d-js v3.2 released in January. It allows you to exclude the unused modules. Refer to the upgrade guide for more details on how to do this. The minimum apk size for Android is 4.4mb .
Related
Is there a workaround to this, as the size of the apk is drastically increased and the library was added through normal procedure -
(compile 'com.github.wseemann:FFmpegMediaPlayer:1.0.4')
and not through manual inclusion or downloading I wonder whether anyone else has this problem.
if you go to the source code of the library, to the releases page (https://github.com/wseemann/FFmpegMediaPlayer/releases) you'll see that you can manually download to your PC, what is normally being downloaded by gradle and then added to your APK.
There you can see it's 50mb zip, file so it's not crazy to imagine 35mb increase in the APK.
That's because it's not a half dozen Java files, like most libraries are, but this have the compiled binary code of the FFMPEG, compiled for each platform Android uses (arm, x86, 32 and 64bits).
So yeah, final conclusion, if you're really gonna use any ffmpeg based thing, your app will take this extra space.
I have a mature app that needs to have an SDK brought in that wraps the camera and makes it do some spiffy processing while it's running. The SDK has come to me in the form of some aar files but my app still lives in Eclipse. Because of my massive, steaming pile of a branding structure and deadlines for this integration the uncertain timeline required to fully migrate to Android Studio will not work (for now) so I'm going for converting the aars and using them in my app via Eclipse.
The problem I'm having is that I need to kick off the activity in the library but even though I fixed up all my build time reference problems, when running the app once I get to the point that is supposed to kick off the activity I get this error.
I've read through and double checked dozens of how-tos explaining how to consume the aar files and I think I've followed every step including:
Unzip the aar files and dress them up as individual library projects, including the file structure with the resources, the manifest, and the .jar
Make the project that needs the libraries add them as such
Add the .jars contained in the library projects to the build path (this step was not listed in most articles, and wasn't necessary for the project to build, but nevertheless it did not help my problem)
Declare the activity in your AndroidManifest.xml that the library brings in and declares in its AndroidManifest.xml
As I've said, everything looks good at build time, so I'm not sure what else to check. Because I'm reading that Gradle and Android Studio mashes manifests together really well, I have a hunch that it's something I'm supposed to regulate between the manifests but I don't know what it could be if that is it. I've wondered if I'm declaring the 3rd party's activity properly, but I'm not sure how to test it because the only way I can think to test it is to provide gibberish for the namespace but even then there are no complaints. I've also tried dissecting the .apk to look at the .dex file but I could not decipher anything useful.
My guess is that the library may not be building properly in eclipse - even before it's being added as a dependency to the application project.
Try looking at out/classes/* and making sure you have a .class file for the activity in question. I think the .class should actually be in the library as well as end up in the application project's out/ dir also.
If there are any native files (x.so) (as I would imagine there might be for spiffy camera stuff), you can look for the x.so files being included in the out/ dirs of both the library and application projects as well as the library.jar file.
Another option to maybe consider for this use case: https://github.com/ksoichiro/gradle-eclipse-aar-plugin
It seems that our app had a bad version of the appcompat-v7 support library. The .jars in it were different sizes than the one that comes with the SDK and several resources were missing. I have no idea how we ended up that way or where this bad version came from. Once I replaced it, things went great.
Later, I did encounter the need to drop in the .so files into the libraries I made that came out of the .aar files as Stad Kurdziel said in his answer, but that was causing a different error (the exception explicitly states that the .so is missing) and I arrived at the solution independently.
My server needs to keep building a large amount of Android projects. All of them are almost identical except for minor change on manifest.xml or any resource file (if it's better for the task) for each build. To reduce cost and improve efficiency, I try to implement incremental build. My planned procedures are:
after the first successful build, skip all the previous
procedures (aapt to generate R.java, adle to make java, etc.)
directly call aapt to make resource files, e.g., *.ap_
call apkbuilder to make classes.dex and usigned.apk
make signed.apk
So my question is whether the above solution is possible? And any clue about how to implement it?
This isn't necessarily a solution for your particular requirements but perhaps it will provide you with some useful pointers.
I have an Antlib that I use for building Android projects. You probably won't want to use it yourself as it has some drawbacks, but it should serve as an example of how to perform the various steps to build an Android app using Ant. In particular, it shows how to call the various Android SDK tools from Ant and how to use the Ant uptodate task and Ant's if and unless attributes to avoid processing files that haven't changed.
The source for the Android Ant macros is here (the Antlib documentation might help you to make sense of what it's doing).
So, I've got a handful of "Utility" style classes in some of my projects. I'm curious if I can move them to an Android Library Project that contains all or most of my non-app specific glue code (wrappers and interfaces, mostly).
So, my question is what happens to the files I don't need in that library. I know Android Library Projects basically just copy their code into the other project, so if I say use 25% of the code in my "general purpose" library, will my app actually contain the bytecode for all 100%, or does it properly strip it down to only the stuff I need.
I had some issues with unused classes in Proguard in the past, so I'm just once-bitten, twice shy with the ADT now...
Unfortunately, all your projects will grow when the library is getting bigger - even if most contents of that library are not used. I tested it myself by creating an app A and a library L. If L is a library used in A, the classes.dex file (and therefore the A.apk file) is growing if I add more classes - even if they are not used.
To sum up: Right now I would create a basic library for certain things that are small and that may be used by many projects, and create a new library for every new component that is going to be larger and only is used by some projects. A good candidate for a new library would be a new UI component with multiple images defined in the resources. A good candidate for the base library are commonly-used methods and things like file caches, for example. Compiled code is compressed quite heavily for Dalvik, which you can see here. (The whole presentation is actually fun to watch :-)
Edit: If ProGuard is activated, it will also remove unused code for you. The default proguard.cfg is sufficient. It will not run on the (default) debug built, but when the final .apk is compiled. So it actually is possible!
I have used 3 level deep Android library projects successfully though it is kind of a pain. The primary use-case is when there are a set of resources and classes that you want to share across a few projects. Since I use a version control system, I would rather not use symlinks.
Note that Android Library projects also suffer greatly when dealing with resources. ADT will rebuild R.java once for each library, and each R.java will contain a copy of all resource ids from all libraries. The core problem here is that resources are regenerated for the entire project as a whole, and there is no way to "build a jar" for a dependency as would be expected with normal "libraries". We tried integrating with OpenFeint, and had all kinds of hell dealing with libraries and dependencies. I think we ended up just merging all the OpenFeint source and resource files into our own project and ditching the "Library" project as it was offering little value.
Android Library projects are a clunky way of sharing code between projects and have a number of drawbacks. I've found that everything accomplished with a Library project can also be accomplished with symlinks (symlink source into two projects). I've yet to find a usecase where an Android Library project offered something that wasn't easy to replicate with other, less fragile means.
I made some changes to Android's bionic in order to run it with a specific application. I'd like to keep these modifications in my source control (SVN). Any idea what the minimal set of files required to still be able to build bionic with Android's regular envsetup.sh->lunch->make workflow?
I got ebuild scripts that build from source android-x86_64-targeting toolchain (including of course bionic).
To build bionic, my script bionic-5.1.1-r29.ebuild takes 6 .zip files from github.com (using SHA sums to get a fixed version). Those 6 files are contents of github repositories
android/platform_bionic
android/platform_build
pbatard/bootimg-tools
pstglia/device-generic-common
pstglia/device-generic-x86_64
llvm-mirror/compiler-rt
I am not sure if the choice is minimal, but the unpacked weight is less than 300M which is a lot smaller than a dozen gigabyte you-know-from-where.