I've got an Android project built under Eclipse-Indigo that works just fine. I recently copied many of the files and rebuilt under Eclipse-Juno. The app runs if you install it and/or run it from Eclipse, but if you try to generate an APK, you get:
Conversion to Dalvik format failed: Unable to execute dex: multiple dex file define Landroid/bluetooth/IBluetooth;
Comparing the directories shows that src/android.bluetooth/IBluetooth.aidl and IBluetoothCallback.aidl are identical, but gen/android.bluetooth exists in the working version but not the broken one. Replacing these files manually makes Eclipse whine, of course, so the question is:
how do I control how Eclipse generates those particular files from the AIDL inputs?
Alternatively, if somebody has an intelligent suggestion as to how to get rid of the stupid error, I'll take that instead :-)
The answer is to NOT install the Android Development Kit, which seems to have borked libraries. Instead, install Eclipse for Java Developers, and install the Android SDK separately. This allowed the correct libraries to appear, and didn't give the stupid errors about duplicate dex files.
Related
Android R IDs are generated by the IDE (Android Studio or Eclipse ADT).
Are they identical between builds?
If yes, will they be the same if generated on different machines?
Firstly, Android IDs are not generated by the IDE but by aapt, a command line tool which is run during a build. Yes, the IDE ultimately triggers it, but it isn't strictly part of Android Studio, it's part of the build tools package.
The numbers are essentially assigned alphabetically, so the resource IDs will be identical for the same project - but not if you modify the resource file tree. I am only prepared to guarantee that on the same file system, operating system and version of build tools. If you change any of those, all bets are off.
Ultimately, relying on this would be a really bad idea, because someone will break it by modifying the project one day, probably sooner rather than later.
I looked into this fairly extensively some years ago when I wrote an APK decompiler for the purposes of patching in resources.
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 am attempting to write Android applications with Scala in Eclipse. The problem I'm running into is that the deployed APK file is much too large - since you can't link Android apps to external libraries, any code used has to be copied into the APK file, but most Scala apps don't need most of the Scala library. Somewhere I read that even a large application can be packaged with only 50kb or so of the Scala library, compared to the 4mb that my Android device is telling me my test app takes up.
I've already tried the Treeshaker plugin for Eclipse, and I can see in the progress window that it is running, but it doesn't seem to do anything. Disintegrating it from my project doesn't have an impact on the final file size. I've also tried configuring Proguard myself, but I can't find a configuration that doesn't either not affect the file size (and I realize that Proguard only runs when use Eclipse's export wizard, which I used to test this) or crash with cryptic error messages, such as "1". (Well, ok, the entire error message is "Conversion to Dalvik format failed with error code 1", which is hardly more helpful because I can't find any clear documentation of that error message and it doesn't tell me what part of my code or configuration is causing the problem...)
So. Any insight on how I can get this working?
Most people use SBT with ProGuard (as far as I know it is run automatically with the sbt android plugin).
Additionally, there is the possibility to ship with two dex files in a apk. This also solves many problems, because most restrictions apply to the dex files, not the final apk.
This is older, but has many useful general information: http://lamp.epfl.ch/~michelou/android/
I use AndroidProguardScala as given here:
https://stackoverflow.com/a/11084146/1287856
It uses Proguard when exporting the application, and it works pretty well.
I am android developer.I am not aware of ant in android .I have downloaded a code from internet But It has file called build.xml but I am not able to find out what it is doing and for what purpose it is used please give some advise or some kind of tutorial.So I can understand its working thanks in advance.
When you are developing your application, Eclipse is the most convenient way of building the project.
However Ant is most useful when you come to produce a release version. You can set up your Ant build, such that it takes the same source files as the Eclipse project, yet produces a signed, zip-aligned version of the apk in completely separate output location.
By means of a custom build.properties file you can specify source and output locations, keystore names and locations and passwords. It also takes care of any Proguard obfuscation you may want.You can do all this from the command line with a single statement and know that you are going through a repeatable process, not vulnerable to a mouse click in the wrong place.
Have a look at Managing Projects from the Command Line and Building and Running from the Command Line
Take the build.xml from the sample project referred to and use it as a basis for your own project. It works pretty much out of the box.
This build file is an alternative (and less common) way to build your projects using ant.
Eclipse (and the Android plugins) do a n excellent job of saving you the trouble - just use the plugin to build your projects and export APKs.
I simply thought I could use jython for developing Android App.
But it was not easier than I thought.
I created android sample project and added jython.jar into the project.
After soon I encountered with "Conversion to Dalvik format failed" error msg.
So I googled almost every pages about that msg.
However I could not find a proper answer.
Closest answer was using "--no-locals" in dx option.
I did it in command console and it seemed to work well. I guess...
My question is...
I want to use the dx option("--no-locals") with eclipse.
Because eclipse automatically copys apk file to the emulator and runs it.
Is it anyway to set dx.bat option ("--no-locals") in eclipse?
Is there anyone who succeed in use of jython for android?
Now I don't know about jython.jar specifically, but it is not given that it is even possible to add every externaljar file to an Android project. It might very well be that your jar is depending on packages that are not included in the Android SDK (because Android isn't an exact clone of Java, just to have mentioned that), and if so it won't be possible to include it.
Try looking very closely on the error stack trace and look for anything indicating there are some missing dependencies. This might give you a clue if this is the case for your jar.