I have a problem with MapView. My map was loaded correctly until I used "targetSdkVersion 19", but since I updated to "targetSdkVersion 29" every time I launch the map activity, the app crashes.
Can anyone tell me what the problem might be?
2019-08-29 17:04:05.679 29021-29119/mcsistemi.tentatavendita E/AndroidRuntime: FATAL EXCEPTION: Thread-8
Process: mcsistemi.tentatavendita, PID: 29021
java.lang.NoClassDefFoundError: Failed resolution of: Lorg/apache/http/ProtocolVersion;
at ce.b(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):3)
at cb.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):3)
at cd.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):14)
at com.google.maps.api.android.lib6.drd.ak.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):4)
at bf.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):22)
at bf.run(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):8)
Caused by: java.lang.ClassNotFoundException: Didn't find class "org.apache.http.ProtocolVersion" on path: DexPathList[[zip file "/data/user_de/0/com.google.android.gms/app_chimera/m/000000c6/MapsDynamite.apk"],nativeLibraryDirectories=[/data/user_de/0/com.google.android.gms/app_chimera/m/000000c6/MapsDynamite.apk!/lib/arm64-v8a, /system/lib64]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:134)
at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
at ad.loadClass(:com.google.android.gms.dynamite_dynamiteloader#19056081#19.0.56 (100400-262933554):4)
at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
at ce.b(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):3)
at cb.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):3)
at cd.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):14)
at com.google.maps.api.android.lib6.drd.ak.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):4)
at bf.a(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):22)
at bf.run(:com.google.android.gms.dynamite_mapsdynamite#19056081#19.0.56 (100400-262933554):8)
Add this under <application> tag in Manifest.xml
<uses-library android:name="org.apache.http.legacy" android:required="false"/>
With Android 6.0, we removed support for the Apache HTTP client.
Beginning with Android 9, that library is removed from the
bootclasspath and is not available to apps by default.
To continue using the Apache HTTP client, apps that target Android 9
and above can add the above line to their AndroidManifest.xml:
Here is more info
by Google
Since you say it started after android sdk 29, the problem could also be from the fact that you haven't changed your mappings to the current androidx mappings in the layout file that bring up this problem
If there is a library call like android.support.v7.widget.CardView in your layout causing the problem, you must change it to androidx.cardview.widget.CardView in android X and sdk 29 upwards..
For more mappings and how its currently written in the layout files, kindly check this link for the other class mappings https://developer.android.com/jetpack/androidx/migrate/class-mappings
Related
My projects Map activity is not working
I just pasted the api key in place google_maps_api.xml
and clicked run
Logcat:
E/AndroidRuntime: FATAL EXCEPTION: Thread-5
Process: com.example.appmy.lofind, PID: 10901
java.lang.NoClassDefFoundError: Failed resolution of: Lorg/apache/http/ProtocolVersion;
at el.b(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):3)
at ek.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):4)
at em.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):51)
at com.google.maps.api.android.lib6.drd.ap.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):11)
at dw.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):16)
at dw.run(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):61)
Caused by: java.lang.ClassNotFoundException: Didn't find class "org.apache.http.ProtocolVersion" on path: DexPathList[[zip file "/system/priv-app/PrebuiltGmsCore/app_chimera/m/MapsDynamite.apk"],nativeLibraryDirectories=[/data/user_de/0/com.google.android.gms/app_chimera/m/00000006/MapsDynamite.apk!/lib/x86, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:126)
at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
at ad.loadClass(:com.google.android.gms.dynamite_dynamiteloader#12848026#12.8.48 (040700-196123505):25)
at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
at el.b(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):3)
at ek.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):4)
at em.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):51)
at com.google.maps.api.android.lib6.drd.ap.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):11)
at dw.a(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):16)
at dw.run(:com.google.android.gms.dynamite_mapsdynamite#12848026#12.8.48 (040700-196123505):61)
E/SchedPolicy: set_timerslack_ns write failed: Operation not permitted
I've found another solution at
Android Google maps java.lang.NoClassDefFoundError: Failed resolution of: Lorg/apache/http/ProtocolVersion
Just add this in your manifest:
<uses-library android:name="org.apache.http.legacy" android:required="false"/>
Update:
Starting from Google Maps SDK version 16.1.0 you can skip adding the solution above as the tag has been added to the AndroidManifest of the maps library.
https://developers.google.com/maps/documentation/android-sdk/releases#2019-02-06
Added the following declaration to the AndroidManifest.xml to support
the Apache HTTP client on Android P and above. After updating to
com.google.android.gms:play-services-maps:16.1.0 you can remove this
line from your own AndroidManifest.xml. (Issue 117591497)
<uses-library android:name="org.apache.http.legacy" android:required="false"/>
The same problem here when using target SDK 28. Reverting to SDK 27 solved the problem.
Don't revert your target SDK.
Better use this solution https://stackoverflow.com/a/50944537/5710605
Put this in the Manifest tag:
<uses-library android:name="org.apache.http.legacy" android:required="false"/>
More info: https://issuetracker.google.com/issues/79478779
as google documentation said:
If you are using com.google.android.gms:play-services-maps:16.0.0 or
below and your app is targeting API level 28 (Android 9.0) or above,
you must include the following declaration within the
element of AndroidManifest.xml.
I recently updated my Xamarin.Android app to Google Play Services v42.1001.0. Without any other code changes, I noticed that when creating a SupportMapFragment, the output throws the following errors:
Rejecting re-init on previously-failed class java.lang.Class:
java.lang.NoClassDefFoundError: Failed resolution of:
Lcom/google/android/chimera/Fragment;
Further down the Stack-trace I see this:
Caused by: java.lang.ClassNotFoundException: Didn't find class
"com.google.android.chimera.Fragment" on path: DexPathList[[zip file
"/data/user_de/0/com.google.android.gms/app_chimera/m/00000006/DynamiteModulesB_GmsCore_prodmnc_alldpi_release.apk"],nativeLibraryDirectories=[/data/user_de/0/com.google.android.gms/app_chimera/m/00000006/n/armeabi-v7a,
/data/user_de/0/com.google.android.gms/app_chimera/m/00000006/n/armeabi,
/system/lib, /vendor/lib]]
As soon as I comment out the SupportMapFragment code, I no longer see this error.
I have:
Made sure I have the latest SDK and Build tools installed
Cleaned/Rebuilt the solution
Verified that my manifest file targets the proper API versions that are supported by the new Google Play Services libraries as per the release notes
It seems to only be happening with the SupportMapFragment. It's also worth noting that my application does use the Multi-Dex build setting.
What else should I try?
I have made an Android plugin to use GCM in my Unity app. When I try to start the RegistrationIntentService (readymade example class from Android Developer Manual site), it causes a crash with the exception
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.google.android.gms.iid.InstanceID" on path: DexPathList[[zip file "/data/app/com.ex.test-1/base.apk"],nativeLibraryDirectories=[/data/app/com.ex.test-1/lib/arm, /vendor/lib, /system/lib]]
I have imported the play-services-9.2.0.unitypackage, without any success. Any help?
For anyone who might want to look for this question answered, I found the solution. The InstanceID.class is not included in the play-services-9.2.0.unitypackage, so include the play-services-iid-9.0.2.aar in the Android -> Plugins folder.
I've been struggling with this for too long now. I hope anyone can help me. Here is my situation:
In our Android app, we route XMLHttpRequests from our WebView via Java/Android so we can add an OAuth2 token and track the requests. This worked fine until Android 5 got released.
Starting Android 5, the following exception is being raised whenever the WebView tries to interact with the exposed object in JavaScript:
java.lang.ClassNotFoundException: Didn't find class "com/company/android/AndroidXMLHttpRequest$AjaxRequest" on path: DexPathList[[zip file "/system/app/webview/webview.apk"],nativeLibraryDirectories=[/system/app/webview/lib/x86_64, /vendor/lib64, /system/lib64]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
at com.android.org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(Native Method)
at com.android.org.chromium.base.SystemMessageHandler.handleMessage(SystemMessageHandler.java:53)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.os.HandlerThread.run(HandlerThread.java:61)
Suppressed: java.lang.ClassNotFoundException: Invalid name: com/company/android/AndroidXMLHttpRequest$AjaxRequest
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
... 6 more
Results on different configurations:
This code works fine on physical and virtual devices running Android < 5.
This code breaks on physical devices running Android 5 and 5.1
This code works fine on a virtual device running Android 5.0
This code breaks on virtual devices running Android 5.1
There is no difference between running a debug or production build
Some info about the code:
* WebViewFragment gets initiated in MainActivity.onCreate.
* WebViewFragment.onCreateView creates object to be exposed to WebView
* JavaScript interface gets added in WebViewClient.onPageFinished
* The class that is exposed is Public
* All methods of the class that are exposed are public and have the #JavascriptInterface annotation
Starting Lollipop, WebView has been decoupled from Android so it can be upgraded via the Play Store. This is also something that shows from the error:
DexPathList[[zip file "/system/app/webview/webview.apk"],nativeLibraryDirectories=[/system/app/webview/lib/x86_64, /vendor/lib64, /system/lib64]]
I looked at the release notes to discover if we have to do something different regarding WebView and addJavaScriptInterface but I can't seem to find anything.
Anyone has any ideas what could be the reason that it fails?
Sorry for that, there was a bug in WebView: http://crbug.com/491800
The bug has been introduced in Android 5.1, so the original 5.0 works fine (the emulator). But on physical Lollipop devices with Play Store, WebView gets updated to a later version (43), which was still broken. The fix came out with WebView version 44, which I think is rolling out just now.
However, there is a workaround. In the injected method that accepts an instance of AjaxRequest, you need to replace the argument type to Object, and then convert to AjaxRequest later in the function (see this comment for an example). This way, WebView will stop trying to look up the class which it can't access at that point.
We have very weird java.lang.ClassNotFoundException on app startup that happens to very small amount of customers (< 1%). We never saw it in dev env and we cannot understand the source of this issue. Here is the stack trace from Google play crash reports.
java.lang.RuntimeException: Unable to instantiate application com.mycompany.myapplication.MyApplication: java.lang.ClassNotFoundException: com.mycompany.myapplication.MyApplication in loader dalvik.system.PathClassLoader[/mnt/asec/com.mycompany.myapplication-1/pkg.apk]
at android.app.LoadedApk.makeApplication(LoadedApk.java:490)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3784)
at android.app.ActivityThread.access$2200(ActivityThread.java:132)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1082)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:143)
at android.app.ActivityThread.main(ActivityThread.java:4268)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: com.mycompany.myapplication.MyApplication in loader dalvik.system.PathClassLoader[/mnt/asec/com.mycompany.myapplication-1/pkg.apk]
at dalvik.system.PathClassLoader.findClass(PathClassLoader.java:240)
at java.lang.ClassLoader.loadClass(ClassLoader.java:551)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at android.app.Instrumentation.newApplication(Instrumentation.java:972)
at android.app.LoadedApk.makeApplication(LoadedApk.java:481)
... 11 more
If the issue only occurs on with signed APKs and you are using Eclipse to Export the Signed APK ...
Before you 'Export and sign an APK' in Eclipse turn off the following setting in the menu [Project > Build Automatically] (then can switch it back on later when you continue developing).
I recently deployed an update to my app, and a user reported a crash the very next day via the Google Play reporting facility. The stack dump was for LoadApk() and the error was in the loading of my Application class. Here is that dump:
java.lang.RuntimeException: Unable to instantiate application com.goalstate.WordGames.FullBoard.library.FullBoardApplication: java.lang.ClassNotFoundException: Didn't find class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at android.app.LoadedApk.makeApplication(LoadedApk.java:516)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4703)
at android.app.ActivityThread.access$1600(ActivityThread.java:175)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1368)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:146)
at android.app.ActivityThread.main(ActivityThread.java:5602)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.goalstate.WordGames.FullBoard.library.FullBoardApplication" on path: DexPathList[[],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:67)
at java.lang.ClassLoader.loadClass(ClassLoader.java:497)
at java.lang.ClassLoader.loadClass(ClassLoader.java:457)
at android.app.Instrumentation.newApplication(Instrumentation.java:981)
at android.app.LoadedApk.makeApplication(LoadedApk.java:511)
... 11 more
I have a library and my Application class was defined in that library. The manifest for my app (which used the library) referred to the class in that library by its full path. It did not have an application class of its own.
All of my in-house testing had not reproduced this problem, and even when I tested (using the Samsung Remote Test Lab) on the same device (actually two different devices, one running 4.3 and one running 4.4.4) as reported the crash (a Galaxy Note II, running Android 4.4), there was no problem.
In searching for information on this I found mention of the fact that different devices may have slightly different approaches to resolving class references, and that is probably why most devices had no problem with my APK, but this particular device (which, unlike my test devices, was provided with its Android flavor by Sprint) did. And similarly, it may be why just one percent of your own customers had the problem, while most did not.
I decided that the best approach would be to make it as easy as possible for even an unsophisticated device to find the classes that were referenced from my manifest file. So, I defined a new application class within the package of the app itself (rather than the library) and I had that class inherit from the application class in my library. The new class was otherwise empty.
I then replaced the full path reference to the application class in the library with a relative reference to the new class I had created in the app itself. So, instead of having:
<application android:name="com.goalstate.WordGames.FullBoard.library.FullBoardApplication"
in my manifest, I had:
<application android:name=".FullBoardWordChumsApplication"
That (according to folklore on this topic) should make it easier for a less sophisticated resolution process to succeed.
I also took the full path that I had been using in the manifest to name my already-local activity class and made it relative (by simply lopping off everything preceding the final dot).
Additional folklore found online indicates that it may help to turn off "Build Automatically" for the project in Eclipse, then exit Eclipse, re-enter Eclipse, and then, after it rebuilds, go directly to Android Tools to export the signed APK (without ever turning on Build Automatically). So, throwing salt over my left shoulder, and saying a prayer to the gods of fragmentation paranoia, I accommodated this superstition in preparing my APK for release.
Does any of this really help? Time will tell, but so far my updated release has not generated any additional crashes.
This Error occurs when in your manifest file in application tag whatever class name you put it is not match with your coding java file .So make a current both in way.