Eclipse + cupcake + other android projects in build path = VerifyError

by Daniel Janev » Wed, 29 Apr 2009 19:22:34 GMT


Sponsored Links
 Hi Guys,

We've had the same problem with ProSyst mBS running on cupcake. After
some checks we found that it depends what JDK you use for building your
jar files before DEXing them. In general here is the info:

We've checked with the following JDK versions: jdk1.5.0_06, jdk1.5.0_10,
jdk1.5.0_12, jdk1.5.0_15, jdk1.6.0_06, jdk1.6.0_10. Only with
jdk1.5.0_06, jdk1.5.0_10 and jdk1.5.0_12 there was no verify errors.

I hope that this can help you.






-- 

Best Regards,
    Daniel
---------------------------------------------------------------
Daniel Janev  Department Manager/Core Platform and Smart Home
ProSyst Software GmbH
1606 Sofia, Bulgaria  Vladajska Str. 48
Tel. +359 (0)2 952 35 81/109  Fax +359 (0)2 953 26 17
Mobile Phone +359 (0)888 678 670
 http://www.prosyst.com   d.ja...@prosyst.com
---------------------------------------------------------------
stay in touch with your product.
---------------------------------------------------------------

--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Is there a way to change mtu size on android phone

Hi all:

I am wondering if there is a way to change MTU size on android phone.

-- 

2. Reasoning behind disabling certain ProGuard optimizations?

In the latest Android SDK Tools (revision 8), ProGuard has been
integrated into the ant build.  This is easier to set up than it was
before (http://www.androidengineer.com/2010/07/optimizing-obfuscating-
and-shrinking.html), but I'm curious about the optimizations that are
disabled by default.

-optimizations !code/simplification/arithmetic,!field/*,!class/merging/
*

#1: code/simplification/arithmetic: This removes things like turning
"3 + 3" into "6".  A shame, but understandable, because there are much
more complicated optimizations to the byte code that Dalvik doesn't
handle well.  This one is completely understood.

#2: !field/*: This refers to the following:
field/removal/writeonly - Removes write-only fields.
field/marking/private - Marks fields as private, whenever possible.
field/propagation/value - Propagates the values of fields across
methods.

#3: !class/merging/*: This disables merging two or more classes
horizontally or vertically (in the same class hierarchy).

The question here is, why would #2 and #3 give Android or Dalvik any
problems?  The classes are valid Java classes in the end.  I suspect
the answer for #2 is that projects built into Android require that the
R.* classes to remain intact.  However, this is NOT the case for
private apps created by developers, unless they use introspection to
access those fields.  There is no need for the R class at all; all of
the constants of that class can be propagated into whomever uses them,
and the the R class can be removed.  For #3, this might have something
to do with the fact that Views referenced in layout .xml files are
dynamically created at runtime by reflection, and maybe merging these
classes together messes them up.  But isn't that prevented by -keep
public class * extends **View?

For over a year I've been obfuscating my app and #2 and #3 have never
been used.  I don't plan on using them from now on, either.  Unless,
someone can clarify why I shouldn't be enabling #2 and #3?

Thanks!
-Matt

P.S. I would recommend adding the following to the next version of the
Android SDK Tool's automatically generated proguard.cfg file:
# Keep classes which are not directly referenced by code, but
referenced by layout files.
-keep public class * extends **View {
    public <init>(android.content.Context);
    public <init>(android.content.Context, android.util.AttributeSet);
    public <init>(android.content.Context, android.util.AttributeSet,
int);
    public void set*(...);
}
This prevents classes which extend View, TextView, etc. classes from
being renamed.  This will avoid ClassNotFoundExceptions when
developers use custom View classes referenced in their layout files.
It will hit some false positives (i.e. a class which ends with View
may not actually be used as such), but that is acceptable IMHO, and
can be easily changed by a developer as needed.

An alternative is to use -keep public class * extends
android.view.View, which removes all false positives, but will add
some missed cases, such as a class which extends TextView.

-- 

3. Arriving HD Review

4. best way to implement this screen layout?

5. Intro to MoMinis

6. MediaRecorder Unsupported parameter on HTC G8 device

7. Video record with MediaRecorder