just50415 / android-rcs-ims-stack

Automatically exported from code.google.com/p/android-rcs-ims-stack
0 stars 0 forks source link

trouble processing "javax/sip/address/Address.class" #34

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
[2011-11-15 19:40:51 - SettingsDisplay] Dx 
trouble processing "javax/sip/address/Address.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.

[2011-11-15 19:40:51 - SettingsDisplay] Dx 1 error; aborting
[2011-11-15 19:40:51 - SettingsDisplay] Conversion to Dalvik format failed with 
error 1

Original issue reported on code.google.com by kevinh...@gmail.com on 15 Nov 2011 at 11:42

GoogleCodeExporter commented 8 years ago
Yes we have seen this problem since Android 4.0 where javax.* class are no more 
authorized. 
Today we have done a copy/paste of the NIST SIP stack in our implementation, 
but since Gingerbread this stack is already part of the OS. So if you are a 
device maker you can remove this classes from the RCS stack an use the SIP 
stack from the OS via a library. If you are not a device maker I think you 
should rename the classes with your own package.
In my side I will check if a common solution may be used.

Original comment by jmauffret@gmail.com on 15 Nov 2011 at 12:42

GoogleCodeExporter commented 8 years ago
How long do you think a clean approach from your side will need?

Original comment by Pietsch...@googlemail.com on 24 Nov 2011 at 5:25

GoogleCodeExporter commented 8 years ago
Today we use Android 3.0 to compile as a workaround. We have not yet decided to 
rename the NIST package.

Original comment by jmauffret@gmail.com on 6 Dec 2011 at 10:48

GoogleCodeExporter commented 8 years ago
On using Android 3.0 sdk also, I am getting the same error while launching. I 
am using Eclipse on Windows machine. I am not able to get apk because of this 
problem

Original comment by moondra....@gmail.com on 9 Dec 2011 at 10:31

GoogleCodeExporter commented 8 years ago
Sorry I want to say Android 2.x.

Then we have started to rename the NIST stack pakage to avoid definitively this 
problem.

This permits also to avoid concurrency problems when the stack is deployed on 
Android OS having already the NIST SIP stack: in fact in this case even I you 
have done  a correction in the NIST stack, your correction was not taken into 
account because it's  the native classname which is loaded by JVM instead of 
your local classname.

Original comment by jmauffret@gmail.com on 24 Feb 2012 at 3:20

GoogleCodeExporter commented 8 years ago

Original comment by jmauffret@gmail.com on 12 Mar 2012 at 9:47

GoogleCodeExporter commented 8 years ago
fixed in next 2.4

Original comment by jmauffret@gmail.com on 12 Mar 2012 at 9:47