I'm getting desperate with this Problem: I want to export/run my Android Application with one additional .jar I added to the buildpath. I'm sure I added it correctly, there are 5 other .jars included and they all work fine.
with this special one I get the mentioned error.
I've already tried everything that can be found in this question:
"Conversion to Dalvik format failed with error 1" on external JAR
and several other links google spat out. The main Problem is, I actually do not understand what the message I appended want's to tell me because if I add all the jars to a "normal" javaproject, it runs perfectly fine...
Developing on Android 4.0.3,
proguard 4.8,
adt 16.0.1.v201112150204-238534,
eclipse 3.7.1.r37
please help me
[2012-07-18 10:45:48 - myapp] Dx warning: Ignoring InnerClasses attribute for an anonymous inner
class (iaik.xml.crypto.XSecProvider$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced
by a compiler that did not target the modern .class file format. The
recommended solution is to recompile the class from source, using an
up-to-date compiler and without specifying any "-target" type options.
The consequence of ignoring this warning is that reflective operations
on this class will incorrectly indicate that it is not an inner
class.
...
...
[2012-07-18 10:45:48 - myapp] Dx warning: Ignoring InnerClasses attribute for an anonymous inner
class (iaik.xml.crypto.XSecProvider$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced
by a compiler that did not target the modern .class file format. The
recommended solution is to recompile the class from source, using an
up-to-date compiler and without specifying any "-target" type options.
The consequence of ignoring this warning is that reflective operations
on this class will incorrectly indicate that it is not an inner
class.
Ill-advised or mistaken usage of a core class (java.* or javax.*) when
not building a core library.
This is often due to inadvertently including a core library file in
your application's project, when using an IDE (such as Eclipse). If
you are sure you're not intentionally defining a core class, then this
is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example, from a
non-Android virtual machine project. This will most assuredly not
work. At a minimum, it jeopardizes the compatibility of your app with
future versions of the platform. It is also often of questionable
legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine distribution,
as opposed to compiling an application -- then use the
"--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact building an
application, then be forewarned that your application will still fail
to build or run, at some point. Please be prepared for angry customers
who find, for example, that your application ceases to function once
they upgrade their operating system. You will be to blame for this
problem.
If you are legitimately using some code that happens to be in a core
package, then the easiest safe alternative you have is to repackage
that code. That is, move the classes in question into your own package
namespace. This means that they will never be in conflict with core
system classes. JarJar is a tool that may help you in this endeavor.
If you find that you cannot do this, then that is an indication that
the path you are on will ultimately lead to pain, suffering, grief,
and lamentation.
[2012-07-18 10:45:48 - myapp] Dx 1 error; aborting
[2012-07-18 10:45:48 - myapp] Conversion to Dalvik format
failed with error 1
This is how my project looks int he explorer:
The problem is that the jar you are including has a class in the java.* or javax.* namespace. dx does not allow this, as mentioned in the last big error message.
If you actually need these classes, you'll need to move them to a different package, using something like the jarjar tool. Otherwise, you'll need to remove them from the jar -- it may be possible to have proguard to remove them before everything gets dx'd, I'm not sure.
I faced the same problem, I finally resolved it by exporting my private library explicitly.
Like:
Project >> properties >> Java Build Path >> Libraries >> Add External Jars.
Note: Removed my all private libraries from libs folder. I know it is not correct but it worked for me.
Thanks,
Anil
Do as follows :
project
> properties
> java build path
> libraries
> remove all including android jars
Now, go the project browser, right click on the project you are working on, then
android tools
> fix project properties.
Do a clean and then build.
Just restart eclipse, and the error won't occur anymore
If you work on Win7 change this line:
call %java_exe% -jar "%PROGUARD_HOME%"\lib\proguard.jar %*
in proguard.bat file to this:
call %java_exe% -jar "%PROGUARD_HOME%"\lib\proguard.jar %1 %2 %3 %4 %5 %6 %7 %8 %9
proguard.bat is in:
[Android SDK Installation Directory]\tools\proguard\bin\proguard.bat
Edit:
I hope a combine of these help you:
1-Try to delete libraries projects from your project.
2-Try to export your project(as archive file),delete project and it's source from workspace and then import it again.
3-Try to remove your jars from path,do clean-build and then add them again to your project.
I had the same error when using my own obfuscated lib jar.
my log:
warning:Ignoring InnerClasses attribute for an anonymous inner class that doesn't come with an associated EnclosingMethod attribte.This class was probably prouduced by a compiler that did not target the morden .class file format...
And I solved it like this:before I obfuscate my jar,I added "-keepattributes EnclosingMethod" to the proguard.cfg(or proguard-project.txt in latest android adt version).
Agree with hasanghaforian. The easiest solution is to remove libraries project.
Right click your project->Properties->Java Build Path then remove Library Projects
Related
I want to migrate my old java code to the java9 modules. E.g. in the classpath there is a jar-file named org.eclipse.jface.3.7.0.v20110928.jar. In the classpath it is referenced as org.eclipse.jface_3.7.0.v20110928.jar. The point in the filename after jface is replaced with an underscore in the classpath. Don't know how it works. Maybe it is because .3.7.0. is not a legal java identifier.
But now I want to use it as a module. I get an error for the modulename. The part '.7.0.' is not allowed, because a number can not be a java identifier. The underscore is a reserved word in java9.
First I used the same name for the module as it saw it in the classpath (org.eclipse.jface_3.7.0.v20110928.jar). But it is an error. The I tried to use the name of the file (org.eclipse.jface.3.7.0.v20110928.jar), same error.
module iDEpdf.src
{
exports org.idepdf.ri.common.utility.annotation;
...
requires org.eclipse.jface.3.7.0.v20110928;
}
'.3.7.0' is marked and the error is 'illegal token'. When I use org.eclipse.jface_3.7.0.v20110928 the marked substring is '.7.0'. The error is the same.
If it is possible I don't want to rename the jar-file. I don't understand how it works for the classpath and I don't understand why it does not work for the module. How should I handle this?
I think you are using a very old library of JFace. You probably need to update or add Automatic-Module-Name.
Since the library doesn’t have a module descriptor yet, the module isn’t recognized as valid.
My question is also: why migrate to the module system before updating libraries to recent versions?
Please also see this question or this one.
I'm trying to optimize / obfuscate a java project with ProGuard.
I extract the project as a runnable jar from eclipse, and it runs just fine.
When I try to compress it with ProGuard, I get thousands of warning and errors, in particular at the end:
Note: there were 1 classes trying to access generic signatures using reflection.
You should consider keeping the signature attributes
(using '-keepattributes Signature').
Note: there were 14 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
Note: there were 2 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
Note: there were 15 accesses to class members by means of introspection.
You should consider explicitly keeping the mentioned class members
(using '-keep' or '-keepclassmembers').
Warning: there were 13229 unresolved references to classes or interfaces.
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
Warning: there were 61 instances of library classes depending on program classes.
You must avoid such dependencies, since the program classes will
be processed, while the library classes will remain unchanged.
Warning: there were 18 unresolved references to program class members.
Your input classes appear to be inconsistent.
You may need to recompile the code.
The external libs I used in the project are added to the jar upon exporting it from eclipse. ("Extract required libraries into jar"). I did not use the "repack into jar" option because it really slows jars down.
The libs in particular are:
import org.apache.poi.ss.usermodel.Row;
import org.apache.poi.ss.usermodel.Sheet;
import org.apache.poi.ss.usermodel.Workbook;
import org.apache.poi.ss.usermodel.WorkbookFactory;
import org.apache.poi.xssf.usermodel.XSSFWorkbook;
Am I doing something fondamentally wrong here?
I have tried without success the suggestions of proguard, and my code compiles in eclipse with no warnings.
It's a very big project so I can't really provide an MCVE, but if someone could point me in the right direction here as to what I'm missing, I'd really appreciate it.
Example of the warning: (It goes on for every single method)
http://pastebin.com/m9hX9LJA
Obviously this might be too general of a problem for you guys to fix, however I might be doing some major obvious mistake that I'm not realizing, that's what I'm going for with this.
Notes are just suggestions, but warnings point out inconsistencies in the input. Notably, the 13229 unresolved references suggest that you are providing the main code of your application (with -injars), but not its libraries (with -injars or -libraryjars). I don't know of Eclipse's Extract or Repack options, but you should check the contents of your input jar(s).
See the ProGuard manual > Troubleshooting > Warning: can't find referenced class.
I am working with ForgeGradle (Minecraft Forge modding platform).
I'd like to obfuscate my mod before publishing but the nature of Forge platform won't allow me to do it by simply running program like ProGuard after compilation (with defined libraries).
Why?
The structure goes like this:
Mod -> Forge -> Minecraft
Since Minecraft uses its own obfuscated classes and ForgeGradle compilator is not DIRECTLY obfuscating Mod's code to fit with Minecraft's one, it is not possible to use MC.jar as library while using ProGuard. Compiled Forge Mod is actually decoded by Forge in runtime using SRG names. The logic behind this is not easily explainable so I'll just note: I cannot obfuscate .jar in a way to fit with libraries.
So I though - I could just take my mod's code (.java files) and rename all fields/methods/classes that are MINE before Forge compilation.
Is there a software that would allow me to pick number of .java files and "obfuscate" them in a way to not reaname references that don't belong to them?
EDIT (more explanation):
Mod's code has 3 states: Development, Compiled, Running.
I will try to give an example:
Let's say there is a decompiled method ItemSword.onHit() inside Minecraft.jar
And its compiled (obfuscated) version look like this: bca.aa(), also all packages are lost (flattened).
In mod's development state of code (.java) to make reference to it we simply make: ItemSword.onHit()
When we compile mod the call will look like this (.class): ItemSword.func_ab4234() - this is the SRG I was talking about.
Now when the mod will be loaded to game, forge will translate "ItemSword" to "bca" and "func_ab4234()" to "aa()"
Because of this I can't even add proper library - there IS NONE. I will always get (in ProGuard) NoClassDefFound Warning and I can't ignore it (it will crash compilation).
So after this edit - Is it still possible to make obfuscation with ProGuard (considering I cannot have "good" library assigned)?
Did you try the proguard options?
http://proguard.sourceforge.net/manual/usage.html
e.g. for Serializable classes and other stuff put this to your proguard configuration (you also can preserve complete classes if you like):
<!-- With this code serializable classes will be backward compatible -->
<keepnames implements="java.io.Serializable"/>
<!-- or for native access:-->
<keepclasseswithmembernames>
<method access="native"/>
</keepclasseswithmembernames>
<!--Preserve all public classes, and their public and protected fields and methods.-->
<keep access="public">
<field access="public protected"/>
<method access="public protected"/>
</keep>
If I got your question, you want to obfuscate your own code, not anything beyond that. That's what ProGuard is actually quite good at. Let's assume you created your classes in the packages com.foo and com.bar. You can use this simple ProGuard command to only obfuscate your own classes:
-keep class !com.foo.**,!com.bar.** { *; }
It tells ProGuard to not obfuscate any members of classes which do not belong to either com.foo or com.bar.
If you are getting NoClassDef errors, you added the wrong library. I guess you are using some kind of IDE (perhaps eclipse). Have a look at the libraries your project references to find the correct library classpath (e.g. a jar file). You basically need to find the classpath used for compiling your code, ProGuard will take that as well and everything should work.
I am trying to emulate some java.lang and java.io classes, e.g. OutputStream within GWT.
I have created a "super" package in my module and referenced it using super-source.
My package structure looks like
com/example/gwt/client
com/example/gwt/server
com/example/gwt/shared
com/example/gwt/super
com/example/gwt/super/java/io/OutputStream.java
com/example/gwt/mymodule.get.xml
and mymodule.xml contains an entry
<super-source path="super" />
Within Eclipse all of the files within the super folder are in error - to be expected because the package structure is wrong. .class files are being generated in the WEB-INF/classes folder, again with the "wrong" package structure so should be ignored.
When I run my application in development mode I get lots of
unable to resolve class java/lang/Object
errors. What am I doing wrong?
Rename ....get.xml to ....gwt.xml?
You can exclude "super" from the eclipse build path.
Try right-clicking or the build path menu exclusion options..
There was nothing wrong with the approach - just the execution.
I had compile errors in the emulated classes which were being masked by the fact that Eclipse was showing errors because of the "incorrect" package structure. Running the compiler from within Eclipse flushed these out.
It also seems that deleting the gwt-unitCache might have helped. As I was moving code around it seems that there were stale entries in here that were still being referenced.
I used proguard to obfuscate my jar file.
During processing I got the following errors:
Initializing...
Warning: tdvep.jmNb: can't find referenced class QSYGWO
Warning: tdvep.qmfsfjttKdvEpNz: can't find referenced class FVTYBN
Warning: tdvep.qsfboBcSw$qsffmtssf: can't find referenced class UGKTLU
Warning: tdvep.qsffmtssf: can't find referenced class DREQUQ
Warning: there were 4 unresolved references to classes or interfaces.
You may need to specify additional library jars (using '-libraryjars').
Please correct the above warnings first.
So guide me to resolve this warnings.
Have you checked the ProGuard troubleshooting section - Problems while processing.
If there are unresolved references to classes or interfaces, you most likely forgot to specify an essential library. For proper processing, all libraries that are referenced by your code must be specified, including the Java run-time library. For specifying libraries, use the -libraryjars option.
For example, if ProGuard complains that it can't find a javax.crypto class, you probably still have to specify jce.jar, next to the more common rt.jar.
If you're missing a library and you're absolutely sure it isn't used anyway, you can try your luck with the -ignorewarnings option, or even the -dontwarn option. Only use these options if you really know what you're doing though.
For example, if you're developing for Android, and ProGuard complains that it can't find a java.awt class, then some library that you are using is referring to java.awt. This is a bit shady, since Android doesn't have this package at all, but if your application works anyway, you can let ProGuard accept it with "-dontwarn java.awt.**".