I have a native application that always worked on Android KitKat with both Dalivik and ART runtimes, but it now crashes on Android L with the following trace:
E/art(12810): dlopen("/data/app-lib/com.mylib.example", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"...
D/AndroidRuntime(12810): Shutting down VM
E/AndroidRuntime(12810): FATAL EXCEPTION: main
E/AndroidRuntime(12810): Process: com.mylib.example, PID: 12810
E/AndroidRuntime(12810): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"...
E/AndroidRuntime(12810): at java.lang.Runtime.loadLibrary(Runtime.java:364)
E/AndroidRuntime(12810): at java.lang.System.loadLibrary(System.java:610)
Is ART runtime in Android L different from KitKat? There is no new NDK available yet, therefore, how to avoid this crash, because it seems that the function issetugid is no longer supported.
The issue has been fixed in the final Android 5.0 release. There is no need to re-compile existing binaries.
However, if the native lib is compiled with target android-21, it fails on previous Android versions (< 5.0)
I think i may have the answer, please correct me if iam wrong.I had faced similar issue and now its fixed (or i have found a workaround rather)
while registering native method to JNI, there are two ways of doing it.
1) Implement JNI_OnLoad() method in your .cpp file and register your native methods with the
appropriate classes.
Check- http://developer.android.com/training/articles/perf-jni.html#native_libraries
example - https://android.googlesource.com/platform/development/+/master/samples/SimpleJNI/jni/native.cpp
2) there is a particular naming convention to follow for the native methods, where the class path (including package) have to be added.
Check - http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp615
Here we need not implement any method. The JVM discovers the native method from the symbol names it self from the binary.
The first method doesn't seem to work in Android ART runtime (ART is Optional in kitkat and it will be the only runtime in Lolipop).I am not not sure why it doesnt work. but i think the reason is because the way ART performs.(The bytecodes are converted and cached during install time itself instead of runtime, so that app runs faster). So since the native libs are not loaded (on_load is not called) the conversion to machine code fails at some point
Use the second method to register natives. it should work.
Only disadvantage is now your function names will be and long and will look horrible (i bet none of the function will fit in 100char limit).bye bye function name readability.
Hope this helps
Cheers,
Shrish
Related
I had been working with the SpotifyAPI for a long time, but randomly it just started to crash on me whenever it trys to load the player. Here is the error I get
12-22 20:20:01.995 28130-28130/com.skyrealm.brockyy.spotifyapi E/AndroidRuntime: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.skyrealm.brockyy.spotifyapi-2/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]] couldn't find "libgnustl_shared.so"
The line of code that I get this error in is
Spotify.getPlayer(playerConfig, this, new Player.InitializationObserver() {
Thank you for your time!
- Rockyfish
I think you might have just hit the 64k method limit
This is when the amount of code you have (including libraries) is more than Android usually packs into a dex file aka your apk. There is a solution
Try this to resolve the solution:
http://developer.android.com/tools/building/multidex.html
fyi it's sad when you hit this limit :-( and usually there is usused code in your project that could do with pruning to tidy it up (including unused library code).
The other possibility is you're writie native (NDK) code, and I can't help you so much with that :)
I'm having a problem with Arcgis SDK for Android which I've never had before.
It seems an issue with its native interface when I call this method:
ArcGISRuntime.setClientId
I have this method inside onCreate() (Application class), so it crashes at the beginning
This is the stack trace:
java.lang.UnsatisfiedLinkError: nativeIsClientIdValid
at com.esri.core.runtime.LicenseImpl.nativeIsClientIdValid(Native Method)
at com.esri.core.runtime.LicenseImpl.b(Unknown Source)
at com.esri.android.runtime.ArcGISRuntime$License.b(Unknown Source)
at com.esri.android.runtime.ArcGISRuntime$License.a(Unknown Source)
at com.esri.android.runtime.ArcGISRuntime.setClientId(Unknown Source)
at com.pkg.manager.AppManager.onCreate(AppManager.java:262)
And this is what I found on Arcgis documentation about this method:
public static LicenseResult setClientId (String clientId)
License an application for basic functionality. This will remove the watermark present in developer mode and must be called in a deployed application. Whenever standard licensed functionality is accessed, a RuntimeException will be thrown.
This method must be called before setting a license with either setLicense(LicenseInfo) or setLicense(String). Note that if any standard licensed functionality is accessed before calling this method, an exception will be thrown when this method is called and the application will remain in developer mode.
Parameters
clientId. client ID to set
Returns
LicenseResult.Invalid or LicenseResult.Valid
(https://developers.arcgis.com/android/api-reference/reference/com/esri/android/runtime/ArcGISRuntime.html)
Any ideas, thank you!
UnsatisfiedLinkError normally means the application can't load a native library it needs, even though the Java wrapper for that library is present. If the Java wrapper were also missing, your code wouldn't compile.
Did you switch from an earlier version of ArcGIS to ArcGIS 10.2.3 in this project? If so, it is possible that the project still has the native libraries from the old version of ArcGIS, which didn't have a setClientId method, even though the project has the Java libraries from the new version of ArcGIS, which do have setClientId.
Assuming you're in Eclipse, right-click the project and choose ArcGIS Tools > Fix Project Properties. That should replace the old native libraries with the 10.2.3 native libraries.
http://maroofi.github.io/ceal/ for removing watermark from screen
I developed applications which use native code. All of a sudden those are not working, giving error "Unsatisfied link error: Couldn't load native library from loader dalvik.System.pathClassLoader, findLibrary returned null. I restarted adt twice. Still getting the same error. Applications which are not using native code, are working fine.
The error implies that the program is not able to find the shared libraries that you would have created.
Which devices did you try it on ?
You can check once if they are available in libs directory of your app . [/data/data/app_id/lib ]. Also check if armv7 support is required and if the directory is there in the libs , is .so present there.
Now it's working. I deleted all my virtual devices and then created a new one. However it's showing "skipped 264 frames. application may be doing too much work on main thread" many times and whenever we press a button, displaying this message in log "error loading /system/media/audio/ui/Effect_Tick.ogg"
thanks.
I am trying to use the EWS Java API v1.1.5 (http://archive.msdn.microsoft.com/ewsjavaapi) in an Android application, and have run into a number of issues.
I downloaded the source, and followed the instructions provided to compile the EWS Java API in Eclipse. In those instructions you are told to download and
add the following pre-requiste jar file dependencies:
commons-codec-1.4.jar
commons-httpclient-3.1.jar
commons-logging-1.1.1.jar
jcifs-1.3.15.jar
I did this, and followed the build instructions with produced the following jar files:
EWSAPI-1.1.0.jar
EWSAPIWithJars-1.1.0
Next, I built a brand new Android application, added the appropriate permissions to the manifest, and then added the following source to the primary activity's OnCreate:
ExchangeService service = new ExchangeService();
ExchangeCredentials credentials = new WebCredentials("emailaddress", "password");
service.setCredentials(credentials);
try
{
service.autodiscoverUrl("emailaddress", this);
}
catch (Exception e)
{
e.printStackTrace();
}
I first tried running this application with the EWSAPI-1.1.0.jar file as a dependency. When I did that, I obtained the following fatal error:
Uncaught handler: thread main exiting due to uncaught exception
java.lang.NoClassDefFoundError:
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager at
microsoft.exchange.webservices.data.ExchangeServiceBase.(Unknown
Source) at
microsoft.exchange.webservices.data.ExchangeServiceBase.(Unknown
Source) at
microsoft.exchange.webservices.data.ExchangeService.(Unknown
Source) at
com.meshin.exchange.ExchangeDiscoveryActivity.onCreate(ExchangeDiscoveryActivity.java:40)
From what I've researched, it seems like this error is being generated because Android comes with the Apache HttpClient 4.0, which doesn't appear
to have the MultiThreadedHttpConnectionManager class anymore.
If I instead remove the EWSAPI-1.1.0.jar, and instead use the EWSAPIWithJARS-1.1.0.jar file as a dependency, I get the following error:
VFY: unable to resolve static method 908: Ljavax/xml/stream/XMLOutputFactory;
newInstance()Ljavax/xml/stream/XMLOutputFactory;
VFY: dead code 0x0008-006a in L
microsoft/exchange/webservices/data/EwsUtilities;.formatLogMessage
(Ljava/lang/String;Ljava/lang/String;) Ljava/lang/String;
VFY: unable to find class referenced in signature (Ljavax/xml/stream/XMLStreamWriter;)
And then eventually...
FATAL EXCEPTION: main java.lang.VerifyError:
microsoft.exchange.webservices.data.AutodiscoverService at
microsoft.exchange.webservices.data.ExchangeService.getAutodiscoverUrl(Unknown
Source) at
microsoft.exchange.webservices.data.ExchangeService.autodiscoverUrl(Unknown
Source) at
com.meshin.exchange.ExchangeDiscoveryActivity.onCreate(ExchangeDiscoveryActivity.java:41)
I am assuming because now I am including the HttpClient 3.1 jar and it is conflicting with the HttpClient 4.0 jar included with the Android libraries.
My question is if there is a way for me to use the EWS Java API in an Android project without having to re-write the parts of it which reference
HttpClient 3.1-specific things which are no longer in 4.0.
You can use microsoft's EWS api for android by doing the following steps,
download the source code available in the URL,
http://archive.msdn.microsoft.com/ewsjavaapi
EWSJavaAPI_1.1.5.zip
Make the changes to above api to work for JDK 1.4 in eclipse like remove override annotations e.t.c
Download source code of javax.* package available in below URL,
http://www.java2s.com/Code/JarDownload/jsr173/jsr173_1.0_src.jar.zip
Download source code of stax api available in below URL,
http://dist.codehaus.org/stax/distributions/stax-src-1.2.0.zip
Keep all the sources under the single java project in eclipse
Open the project explorer and select the package which are starts with "javax" and rename to your company name eg: com. Note: Eclipse will ask for all the naming contexts will change then click OK.
Export all the java sources to one single jar file.
Then You good to go to use the jar in Android application with out any problems.
I used the same way explained above and it worked in android application 100% perfectly.
This isn't a useful answer but I've also been struggling to look at the EWS API over the last couple of weeks, with no success.
The main issue I've found is it references a lot of the javax APIs which aren't on Android. There's a hack you can find that explains how to "re-class" these but I've not got it working yet; in addition, the DnsClient references some namespaces that jarsearches only return for rt.jar - the main runtime. And including this in an Android app would just be crazy!
Before finding the API I was trying to use KSOAP to communicate with EWS but again ran into problems - you need to be able to do NTLM and SSL and I couldn't find any way of combining all these with KSOAP in any simple way.
The EWS API looks the way to go (why re-invent the wheel) but getting it working on Android looks very tricky (if not impossible)
Please check this library for the solution
I am loading one shared library from another. Lets say foo2.so from foo1.so
I am using dlopen followed by dlsym
dlopen succeed with proper handle but dlsym returns with "symbol not found" error .I have used dlerror to print the error.
These are the things i tried. In foo2.so .mk file I added
LOCAL_LDFLAGS += -Wl,--export-dynamic.
I checked the symbol in foo2.so using nm and it is there.
Both the modules are in C except one wrapper file in foo1.so which is in C++, Calling file is in C.
Can any one suggest whether i missed any thing . I am running this on android emulator on froyo.
I would be tempted to poke around at the implementation level and verify things. Look in /proc/PID#/maps and make sure both libraries are loaded.
objdump both caller and callee and make sure that C++ bit didn't mangle the name.
Are you using a suitable RTLD_ flag, and is dlsym getting a valid handle returned by dlopen ?
Can you build (a simplified version of) the two libraries and test executable for a desktop linux or cygwin in order to make sure what you want to do is generally workable - ie, that the problem is android-specific?