Android project from Eclipse... classes.dex issues

I am trying to get my project (formerly working in Eclipse) up and going in the IDEA 11 trial period.

The project structure is thus (for one of several apps in the project) is as follows.  This is, I should point out, as it worked in Eclipse and is nearly working under IDEA.

The project is complex, as the apps use code that was underneath the SDK, but I should add that they've been in release for over 2 years.

Modules:

  1. GV -- a third party non-Android project.  This is only one without Android Facet.  Project SDK (1.6)
  2. FB -- a third party Android Library -- Facebook's,  SDK=2.0
  3. PA -- a third party Android Library, SDK=2.0
  4. CD -- an Android library dependent on the three above, SDK 2.0
  5. BT -- an Android library dependent on nothing, SDK 2.2
  6. CD2 -- Android library dependent on BT and CD, SDK 2.2
  7. APP -- this very tiny module generates my application.  Depends on CD2, SDK 2.2


I get many errors when trying to make classes.dex


Error:UNEXPECTED TOP-LEVEL EXCEPTION:
Error:java.lang.IllegalArgumentException: already added: Lcom/me/CD/CD$26;
Error:at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
Error:at com.android.dx.dex.file.DexFile.add(DexFile.java:163)
Error:at com.android.dx.command.dexer.Main.processClass(Main.java:486)
Error:at com.android.dx.command.dexer.Main.processFileBytes(Main.java:455)
Error:at com.android.dx.command.dexer.Main.access$400(Main.java:67)
Error:at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:394)
Error:at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)
Error:at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)
Error:at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)
Error:at com.android.dx.command.dexer.Main.processOne(Main.java:418)
Error:at com.android.dx.command.dexer.Main.processAllFiles(Main.java:329)
Error:at com.android.dx.command.dexer.Main.run(Main.java:206)
Error:at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Error:at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Error:at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Error:at java.lang.reflect.Method.invoke(Method.java:597)
Error:at org.jetbrains.android.compiler.tools.AndroidDxRunner.runDex(AndroidDxRunner.java:120)
Error:at org.jetbrains.android.compiler.tools.AndroidDxRunner.main(AndroidDxRunner.java:230)
Error:at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:75)
Error:java.lang.IllegalArgumentException: already added: Lcom/me/CD/ClassNameHere;
Error:at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:135)
Error:java.lang.IllegalArgumentException: already added: Lcom/me/CD/CD$21;
Error:java.lang.IllegalArgumentException: already added: Lcom/me/CD/AppList$1;
Error:java.lang.IllegalArgumentException: already added: Lcom/me/CD/R$attr;
Error:java.lang.IllegalArgumentException: already added: Lcom/me/CD/CD$15;


I also get this odd one with a preachy postamble.  Might this have to do with module "GV"?  Should GV's SDK be an Android one or Java 1.6?


Error:trouble processing "java/awt/font/NumericShaper.class":
Error:Ill-advised or mistaken usage of a core class (java.* or javax.*)
Error:when not building a core library.
Error:This is often due to inadvertently including a core library file
Error:in your application's project, when using an IDE (such as
Error:Eclipse). If you are sure you're not intentionally defining a
Error:core class, then this is the most likely explanation of what's
Error:going on.
Error:However, you might actually be trying to define a class in a core
Error:namespace, the source of which you may have taken, for example,
Error:from a non-Android virtual machine project. This will most
Error:assuredly not work. At a minimum, it jeopardizes the
Error:compatibility of your app with future versions of the platform.
Error:It is also often of questionable legality.
Error:If you really intend to build a core library -- which is only
Error:appropriate as part of creating a full virtual machine
Error:distribution, as opposed to compiling an application -- then use
Error:the "--core-library" option to suppress this error message.
Error:If you go ahead and use "--core-library" but are in fact
Error:building an application, then be forewarned that your application
Error:will still fail to build or run, at some point. Please be
Error:prepared for angry customers who find, for example, that your
Error:application ceases to function once they upgrade their operating
Error:system. You will be to blame for this problem.
Error:If you are legitimately using some code that happens to be in a
Error:core package, then the easiest safe alternative you have is to
Error:repackage that code. That is, move the classes in question into
Error:your own package namespace. This means that they will never be in
Error:conflict with core system classes. JarJar is a tool that may help
Error:you in this endeavor. If you find that you cannot do this, then
Error:that is an indication that the path you are on will ultimately
Error:lead to pain, suffering, grief, and lamentation.


Lastly, some errors finding AIDL code within module CD, seemingly because different modules have their own resources to provide in the end:


Warning:warning: /Users/tone/Documents/code/workspace/CD/bin/classes/com/me/CD/R$drawable.class won't be added. Class R$drawable already exists in classpath
Warning:warning: /Users/tone/Documents/code/workspace/CD/bin/classes/com/FB/android/R$string.class won't be added. Class R$string already exists in classpath
Warning:warning: /Users/tone/Documents/code/workspace/CD/bin/classes/com/FB/android/R$layout.class won't be added. Class R$layout already exists in classpath
Warning:warning: /Users/tone/Documents/code/workspace/CD/bin/classes/com/FB/android/R$attr.class won't be added. Class R$attr already exists in classpath
Warning:warning: /Users/tone/Documents/code/workspace/CD/bin/classes/com/FB/android/R$menu.class won't be added. Class R$menu already exists in classpath
Warning:warning: /Users/tone/Documents/code/workspace/CD/bin/classes/com/FB/android/R$raw.class won't be added. Class R$raw already exists in classpath
Warning:warning: /Users/tone/Documents/code/workspace/CD/bin/classes/com/FB/android/R.class won't be added. Class R already exists in classpath



Is the issue apt to be one of which module should depend on which others, and whether they should do so via "compile" vs "provided" or similar?  Those options mystify me, frankly.

Thanks in advance for any advice.

Tony

2 comments
Comment actions Permalink

Hello.

1. Choose Navigate | Class (Ctrl+N) and type ClassNameHere. What do you see here?
2. Third-party Android libraries are added as simple modules in the project, aren't they? (So, there are no any differences between 3rd party Android libraries and your own ones)
3. Make sure that you checked "Is library project" in Android facet settings for every Android library module.
4. Find some duplicating class file (ex "ClassNameHere.class") in the output directories of your project. How match did you find? In what modules?
5. If possible, perform this search also in archives ("classes.jar" files in output directories of Android library modules)

Note, that all dependencies between Android libraries and also "Android app"->"Android library" must be simple module dependencies (not dependency on some jar or output folder)

0
Comment actions Permalink

> 1. Choose Navigate | Class (Ctrl+N) and type ClassNameHere. What do you see here?

It finds the Java file no problem

> 2. Third-party Android libraries are added as simple modules in the project, aren't they? (So, there are no any differences between 3rd party Android libraries and your own ones)

Yes.  I should not have mentioned their third-party nature, really.

> 3. Make sure that you checked "Is library project" in Android facet settings for every Android library module.

Done.  Only those generating an APK should not be checked as Android libraries?

> 4. Find some duplicating class file (ex "ClassNameHere.class") in the output directories of your project. How match did you find? In what modules?

> 5. If possible, perform this search also in archives ("classes.jar" files in output directories of Android library modules)

> Note, that all dependencies between Android libraries and also "Android app"->"Android library" must be simple module dependencies (not dependency on some jar or output folder)



I have created Module dependencies only.

Let me pose a question in the hypothetical which I think asks the real question I need answered.

Say I have a CoreLib library, and an Android4Lib library that depends on CoreLib and offers that lib's abstract functionality using Android4-compatible code, and a third project Android4APK that delivers an APK offering the app in Android 4 form:

1.  I'm guessing both CoreLib and Android4Lib need to be marked as Android Libraries, but Android4APK does not
2.  All 3 need the Android facet, and SDK=(some suitable Android SDK)

But...
Should Android4Lib "export" CoreLib?
Should Android4APK depend on CoreLib, or simply upon Android4Lib?

tone
0

Please sign in to leave a comment.