I am facing a strange problem for which I am totally unable to find the correct reason.
When I build an android project on my system(using eclipse and OS CentOS: Linux(Fedora)), the .apk size is 15Mb while when I compile the same code on my colleague's system(using eclipse On windows XP), the build size is 7Mb which is half the size of .apk build on my system.
Please help...
Check your /lib and /res folder if you are including unwanted libs and unwanted resources
The problem was in my libs.
There were .so files in my libs that were not being committed to Svn as subclipse by default ignores .so files . I found the issue here I fail to commit a .so library file using subclipse
and the accepted answer of this question was perfect solution.
So now the .Apk on my colleague's system is same size as on mine(15mb).
I found a similar problem when moving source files from Windows to Linux. It seems there are various files that Windows sometimes adds to project folders such as Thumbs.db which, depending on the amount of project resources, can get fairly sizeable. On Windows file systems, these files are most likely detected as hidden when Eclipse/Android SDK reads through them to build the APK, on Linux however these would not be considered hidden and therefore could be getting bundled with the APK.
It would be worth checking the contents of the folders on both systems for hidden files and clean them.
Related
I have an Android Studio projet that depends on an external .so file compiled with another IDE. Whenever my .so is linked, I copy and paste it into the src/main/jniLibs/armeabi-v7a folder of my Android project, erasing the existing one, if any.
However, most of the time, it seems like Android Studio is not taking that change into account and keeps reusing the old version of the .so file. Sometimes it works, sometimes it doesn't, and I have not figured out what exactly is causing it to or not to work.
How can I do for the .so file to be updated ? I saw an SO answer providing a piece of gradle script to manually copy the .so file, but it doesn't fit my particular case since I have multiple .so files, one debug and one release for each CPU.
When I install my app on a genymotion simulater device,it can not be installed well,on console I got "INSTALL_FAILED_CPU_ABI_INCOMPATIBLE"
I trid another app,it installed fine.I do not know why.
The application (certainly a game) must be ARM only.
Genymotion is a x86 platform, so compile the application to target x86.
You may be able to install ARM support manually :
http://forum.xda-developers.com/showthread.php?t=2528952
If you are using IntelliJ it may be related to the project's default configuration. IntelliJ will assume, unless otherwise specified, that Native libraries will be stored in the Libs folder. This is usually where developer store their JAR libraries. IntelliJ build process will package up the JAR file into the Native file folder in the APK.
If you experiencing this problem, you can find a good How-to:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE Intellj
This helped to resolve the issue I had.
You might want to check out my answer here:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE on device using intellij
I know it's written for IntelliJ, but you could be running into a similar issue with Eclipse where it thinks that some normal Java files or jar libraries are native code and including it in the compiled APK. A quick way to find out is to open up the final APK (it's just a jar file, so most utilities should be able to decompress it) and make sure that the only things you see are META-INF, res, AndroidManifest.xml, classes.dex, and resources.arsc. It's possible that there are other valid files in a normal Java Android application, but in general if you see anything else in there, particularly a libs folder, it's probably the result of the compilation process thinking that those other things are native libraries (compiled C/C++ code using the JNI).
If this is the case, you'll need to configure Eclipse to not interpret the Java libraries you're using as native code. Now, I don't personally use Eclipse so I don't know where the proper settings would be, but based off of this answer, it looks like Eclipse automatically assumes that the libs folder in the root of your project contains native libraries. The easiest solution may be to move any Java libraries you are using into a different folder (such as libraries).
http://blog.iteedee.com/2014/02/android-install_failed_cpu_abi_incompatible-intellj/
The INSTALL_FAILED_CPU_ABI_INCOMPATIBLE error is generated when you attempt to install an android application on a device with an unsupported CPU architecture. This error is usually related to the native libraries that are not packaged up for the device’s CPU architecture (ie: x86, ARMv6, ARMv7, etc).
Now, if you have an application that doesn’t use any native libraries or *.so file you might be scratching your head on this one. If you use IntelliJ IDEA IDE for your android development it might be packaging all of your related .JAR file in to the Native Library file location in your APK.
The cause of the same problem was different in my case.
I had added some dependency jars in /libs directory of my Android app project. One of these jars had exported library in jar format; i.e. a jar within a jar file. I've noticed that the apk created using jars with such structure are incompatible with x86 based devices (don't know why).
I use two computer for coding. My desktop pc and the notebook. I sync the two computers with dropbox. How can I import/load a project on each of this two computers? The project base folder is different on each computer. When I try to load/import a project which is created on the other computer it loads the project but I got a error with a wrong path.
"Gradle "Test2Project" project refresh failed:
Could not fetch model of type "IdeaProject" using Gradle distribution "http://services.gradle.org/distributions/gradle-1.6.zip".
Project directory "C:\Users\thomas\AndroidStudioProjects\Test2Project" does not exist."
The wrong pfad is the right pfad on the other computer. How can I import Android Studio projects so that it works even on another computer with a different folder structure?
Like the others i agree, that using a VCS would be the best solution. Even though you can try to filter all android studio related files (like *.iml, .idea folder and local.properties). I don't know if you can do this with dropbox or if you need some kind of 3rd software.
After that you should be able to make source code changes on both computers without greater problems. (You may have to declare project dependencies changes for the android studio twice)
Builds depending on the build.gradle files should work to. But again: using a VCS is the better way to go.
Go for git, you can use bitbucket.com as a free remote repository.
This is a problem I have ran into when trying to store Android projects in a Dropbox folder. What happens is that Machine 1's IDE is mapping system resources (like the SDK) as being in that machine's filesystem. When you go to Machine 2, everything will work EXCEPT for what you expect--because the SDK will probably be in a different spot!
One way to get around this is to use your VCS (dropbox, git, whatever) as a repository for JUST your source files, and then have a local project created on each machine that reads from the Dropbox folder. This requires two separate projects that are mapped differently, but that have the same source folder.
I discovered this problem when I tried to load up an Android project on a new install on a Mac machine:
Do you see what's happening there? My Mac Android Studio is saying, "Hey, I don't see where "C:\Android\SDK is, but I do see that you have an Android SDK in a different folder, so I'm going to update your project files to reflect the actual location of the SDK."
In my opinion, the only way around this is to create your project on both machines, and version control your source and assets folder. If you don't create the project separately on each machine and use VCS for just the source and assets, the only way to get around build and filepath errors is to store your SDK in the same folder on each machine. This worked for me when I was building on a Windows desktop and Windows laptop, but no longer works for me since I am using a Macbook Pro.
I know this was questioned about 4 years ago, but this is up to now still an issue. Using a VCS seems like a good solution, but for me it is simply more overhead than i want to have. I also use Dropbox to synchronize my folders and the history they provide is for my private programming needs good enough. So i think, it would be good, if android studio simply uses relative paths.
I know it needs some system paths and it does a good job in looking at the local.properties and setting it to the correct place when the project is loaded.
The main problem with using Dropbox are the build-directories. There are many many references to fully qualified paths in the files within these directories. So my solution was to exclude the build-directories from Dropbox-synchronisation.
When you work at your laptop, build the app, create new files, change files or delete files, the build on your pc will be completely outdated when you switch back to it. but android studio will recognize this and do a fresh build when you start your project for the first time after working on the laptop.
so the biggest problem at this point is the file local.properties and this is handled correctly by android studio. it may be a good idea (or a really bad one, i don't know the drawbacks) when the build system wouldn't write fully qualified paths in the files within the build directory.
But up to now this is my solution for using Dropbox and not using a VCS:
exclude build-paths from Dropbox synchronisation
i hope this helps somebody.
It's all in the title really: I don't want to include folders that are generated by Eclipse - I just want to know what's the minimum I need to include in my SVN backup.
I'm guessing AndroidManifest.xml, src, assets (empty in my case) and res. What about libs, which contains android-support-v4.jar? Anything else?
My SVN is external to eclipse as I have several projects in different languages and TortoiseSVN itself, which I use, is installed on my PC. So I don't want to use any integrated plug-in.
Thanks.
PS: I checked other similar questions/answers but none really answered this.
First off, SVN is not a backup, it's version control. Don't use it as a backup.
Second, there is no difference if you use the integrated plugin, the command line client or some UI tool.
Finally, what you don't want to put in VC are generally generated files and files specific to your workspace (if multiple people are working on the code). For Android projects, generated files include the bin/ and gen/ directories. You might want to put libs/ in VC for convenience, but it is not strictly necessary, since you can get the libraries from somewhere else. On the other hand putting them in VC guarantees that everyone is using the same version. Workspace-specific files are Eclipse's .settings/, .metadata, etc. It is also advisable to keep your project code and the Eclipse workspace directory separate, so that you can recover easily when Eclipse messes up.
So, exclude the above and put everything else in VC.
Is there any way to exclude certain files under the /res folder from being processed by the Android builder?
I have several Android projects, which I build using Eclipse. I uploaded these projects in our version-control system. The problem is, the version-control adds some "project.pj" file to every folder.
Because of these project.pj files, my projects won't build in Eclipse anymore. I get errors because the builder tries to process these files under /res. I know I can exclude these files for the /src and /gen folders, but how do I exclude them for the /res (and /assets) folders?
If you prefix any file name with a period (.) it'll be hidden from Eclipse and not included in your build.
If you're on a computer running Windows, you'll still be able to see them without issue in the Explorer. If you're on a Mac, you'll need to make sure that hidden files are being revealed if you ever want to find the file again.
actually, there are a couple of ways to get aapt to ignore such resources.
one such way is with the --ignore-assets to command-line invocation, if you can affect that (perhaps in build.xml if used).
you can also use aapt.ignore.assets= in your ant.properties, if you have that.
aapt is the program that processes the files under res/. There's no way to tell it to ignore certain files. So, short answer: you can't. Your VCS is poorly suited to Android projects. Have you heard of git?
That said, your build system can be extended to move these unwanted files out of the way, run aapt, and then move them right back. As you're using Eclipse, accomplishing this means hacking its Android plugin to add these additional steps. Or perhaps writing your own plugin that performs these steps around a call to the Android plugin -- I've never hacked on Eclipse myself, and wouldn't want to. To have any other build system (e.g. using maven, or ant, or make, or scripts) do this is as simple as understanding how that system does anything. Eclipse is just way more involved. As a final option, you can write your own scripts in the project directory that move these .pj files around, and run these scripts yourself at appropriate times, without getting any help from Eclipse.
Use ant to control build, compile process.