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 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
stay in touch with your product.


Other Threads

1. Detecting if microphone is mute during a call


I would like  to detect if microphone in the device or in a headset is
mute during a call.
Currently I've taken the following approach (unfortunately - it does
not work):
1) register PhoneStateListener to detect when a call is started/
2) when call is started then I start a thread that periodically calls
audioManager.isMicrophoneMute() method to discover a microphone
status. (audioManager is obtained by calling getSystemService
3) when call is finished I stop a thread started in bullet 2

Unfortunately audioManager.isMicrophoneMute() always returns 'true',
does not matter if I select or deselect the 'Mute' option in the menu
during a call.

Does anybody know if it is possible to detect the state of a
microphone during a call?
I'd be very grateful for help.



2. Debugging in Eclipse - current line wrong for methods with multiple return points

You can view the code and "positions" tables with:

% dexdump -d myapp.apk

Search for your method (DebugProblem1.m).  Skip past the instructions
to find the "positions" table, which has pairs of Dalvik instruction
offsets and line numbers.  When I do this in a test class that matches
yours I get:

000108:                                        |[000108] Foo.m:(I)I
000118: 1210                                   |0000: const/4 v0, #int
1 // #1
00011a: 3302 0300                              |0001: if-ne v2, v0,
0004 // +0003
00011e: 1200                                   |0003: const/4 v0, #int
0 // #0
000120: 0f00                                   |0004: return v0
      catches       : (none)
      positions     :
        0x0001 line=18
        0x0003 line=19
        0x0004 line=22
      locals        :
        0x0000 - 0x0005 reg=1 this LFoo;

The code is very simple:

 0000 load 1 into v0
 0001 if the method argument (v2) does not equal v0, branch to 0004
 0003 load 0 into v0
 0004 return v0

As you can see, there's only one "return" statement, shared by both
code paths.  This is why the de{*filter*} leaps around.  The situation
could be avoided by adding additional instructions, but that's
generally undesirable.

It's a bit like debugging native code built with "-g -O2".  (That
thought inspired me to try it with "dx --no-optimize", but that still
used a common return statement and suffered from the same problem.)

The Java bytecode for this class does have two returns, and would
display correctly in a de{*filter*}:

private int m(int);
   Stack=2, Locals=2, Args_size=2
   0:   iload_1
   1:   iconst_1
   2:   if_icmpne       7
   5:   iconst_0
   6:   ireturn
   7:   iconst_1
   8:   ireturn
   line 18: 0
   line 19: 5
   line 22: 7

Bottom line: this is an artifact of the conversion from Java bytecode
to Dalvik bytecode.


3. TabActivity + TabContentFactory + inflated layouts... problem

4. Layout file not recognized as such in eclipse

5. Max size of URL on the browser and POST

6. Omx video encoding in Cupcake

7. create an image "on the fly" and assign it to a button