just50415 / android-rcs-ims-stack

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

problem of including core library in high version of sdk(tools) #42

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1.open project in eclipse
2.clean the project 
3.run project

What is the expected output? What do you see instead?
it should run in my phone which is connected to pc normally, instead, it output 
this:

[2011-12-29 16:52:11 - core] 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-12-29 16:52:11 - core] Dx 1 error; aborting
[2011-12-29 16:52:11 - core] Conversion to Dalvik format failed with error 1

What version of the product are you using? On what operating system?
my version is core 2.3.0, on win7 home pre x64

Please provide any additional information below.
i have googled about it, found some explanation
http://code.google.com/p/dalvik/wiki/JavaxPackages

it seems to android reject defining package named anroid.*, java.*, javax.*, 
but in core stack, we used javax.sip.*
my eclipse is 3.7.1, adt version is 16.0.1, android sdk tools version is 16, 
android sdk platform-tools version is 10.

so i have to find out my old adt and sdk tools which i used ago, it worked 
normally, the old version is eclipse 3.6.1, adt version 10, sdk tools version 8,
sdk platform tools version 1.

do you have any solution for it?

Original issue reported on code.google.com by YunfeiT...@gmail.com on 29 Dec 2011 at 9:36

GoogleCodeExporter commented 8 years ago
Looks like a duplicate of issue #34.

Original comment by pkurp...@gmail.com on 30 Dec 2011 at 12:13

GoogleCodeExporter commented 8 years ago
Any news with this? Seems that issue #34 workaround doesn't fix this.
Using Tools version 16 and platform-tools version 10.

We found also another related error for android-sdk, but solution doesn't seem 
to help.
http://code.google.com/p/android/issues/detail?id=18359

Original comment by tekk...@gmail.com on 5 Jan 2012 at 3:06

GoogleCodeExporter commented 8 years ago
I was able to build this using the following method:

1. Generate build.xml (need to be in "core" directory): 
     /opt/android-sdk-macosx/tools/android update project -p .
2. Hack dx to force this option. I did it by copying dx to dx.orig and 
replacing dx with the following script:

#!/bin/bash

echo "DEX arguments $*"

if [ "--dex" == "$1" ] ; then
                shift
fi

echo "New DEX arguments: --dex --core-library $*"

exec `dirname $0`/dx.orig --dex --core-library $*

3. Android's build.xml will pick up libs/rcs_api.jar automatically and then 
complain about the duplicate classes. I have added "jar.libs.dir=libs-extra" to 
local.properties to work-around this problem.

Compiles fine on Mac now

Original comment by ngrigor...@gmail.com on 17 Feb 2012 at 4:13

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
This problem occurs only since Android 4.x platform. So I stay with my older 
platform.

Original comment by jmauffret@gmail.com on 23 Feb 2012 at 8:52

GoogleCodeExporter commented 8 years ago
I've a problem with Android versions and I tried everything mentioned in this 
issue.
My client works right with Android 2.2.1. With Android 2.3.5 I get the next 
error when I turn on the RCS service:

SIP stack initialization has failed
otro.sip.PeerUnavailableException: Failed to initiate 
gov.nist.javax.sip.SipStackImpl
    at otro.sip.SipFactory.createSipStack(SipFactory.java:60)
    at com.orangelabs.rcs.core.ims.protocol.sip.SipInterface.<init>  
        (SipInterface.java:264)
    at com.orangelabs.rcs.core.ims.network.sip.SipManager.initStack
        (SipManager.java:122)
    at com.orangelabs.rcs.core.ims.network.ImsNetworkInterface.register
        (ImsNetworkInterface.java:448)
    at com.orangelabs.rcs.core.ims.network.ImsConnectionManager.run
        (ImsConnectionManager.java:452)
    at java.lang.Thread.run(Thread.java:1019)
Caused by: java.lang.ClassCastException
    at java.lang.Class.asSubclass(Class.java:1470)
    at otro.sip.SipFactory.createSipStack(SipFactory.java:56)
    ... 5 more
Can't instanciate the SIP stack
com.orangelabs.rcs.core.ims.protocol.sip.SipException: Can't create the SIP 
stack
    at com.orangelabs.rcs.core.ims.protocol.sip.SipInterface.<init>
        (SipInterface.java:331)
    at com.orangelabs.rcs.core.ims.network.sip.SipManager.initStack
        (SipManager.java:122)
    at com.orangelabs.rcs.core.ims.network.ImsNetworkInterface.register
        (ImsNetworkInterface.java:448)
    at com.orangelabs.rcs.core.ims.network.ImsConnectionManager.run
        (ImsConnectionManager.java:452)
    at java.lang.Thread.run(Thread.java:1019)

I changed javax.sip.* for otro.sip.*

Do you have any solution for it?

Original comment by natalia....@gmail.com on 5 Mar 2012 at 1:28

GoogleCodeExporter commented 8 years ago
It's not so easy to change the classname in NIST SIP stack because some classes 
are loaded dynamically.

We have done the work also in our side and this will be available the 12/13 of 
March.

Original comment by jmauffret@gmail.com on 5 Mar 2012 at 1:55

GoogleCodeExporter commented 8 years ago
I am facing the same problem that natalia is facing(Comment 6). I am using 
2.2.8 version with some UI enhancements on top of it.

Is there any other work around to get rid of sip stack initialization error?

Original comment by Anupama....@gmail.com on 21 Nov 2012 at 5:00