I'm using classes from Android's BitmapFun sample code and have been running into a problem with certain devices(My app doesn't crash on all the devices I have tested, but on other peoples).
Note: The version of Android which this happens on has been: 2.3.3-2.3.7, 4.0.3-4.0.4, 4.1 and 4.2
In my Google developer console, I getting the following stack trace:
java.lang.RuntimeException: Unable to start activity
ComponentInfo{com.question/com.question.ui.question}: java.lang.NullPointerException
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2077)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2104)
at android.app.ActivityThread.access$600(ActivityThread.java:134)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1247)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:4624)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:809)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:576)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.question.util.ImageCache.getDiskCacheDir(ImageCache.java:568)
at com.question.util.ImageCache$ImageCacheParams.<init>(ImageCache.java:488)
at com.question.ui.question.onCreate(question.java:58)
at android.app.Activity.performCreate(Activity.java:4479)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1050)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2041)
... 11 more
I have looked into this and have found a question with the same problem. I have made some adjustments that are suggested from that answer and same problem still persists.
Code that is causing the problem:
public static File getDiskCacheDir(Context context, String uniqueName) {
// Check if media is mounted or storage is built-in, if so, try and use external cache dir
// otherwise use internal cache dir
final String cachePath =
Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState()) ||
!isExternalStorageRemovable() ? getExternalCacheDir(context).getPath() :
context.getCacheDir().getPath();
return new File(cachePath + File.separator + uniqueName);
}
if anyone would know what the issue is here and could explain, that would be of help!
I experienced this issue and discovered my AVD emulator was not configured correctly. Specifically, the null pointer is due to the lack of storage space defined and assigned to the Virtual Device.
To fix the problem create a new or edit your Android Virtual Device with SD Card storage. In Eclipse: Select the Andoid Virtual Device Manager ICON=> Create New=>... Near the bottom of the page is a section called SD Card: Enter a value for SD Card size.
Here is a link that describes how to configure the AVD emulator with the proper storage.
Here is a link that provides a good technical definition why the NullPointerException is generated.
Related
Today we got a strange crash. During the first installation the app downloads and unzips openh264 to the internal directory of the app, happens on a Schedulers.io() thread from rxAndroid.
This is the first crash of this kind (>5k installations) and I found this link (very interesting blog by the way) with a matching error message. I'm not sure if really someone tried to replace the openH264 lib or if someone tried to install the apk file on a x86 device. I'm still using 1.4 of openH264 and have read the 1.5 release notes. There is no hint of security fixes.
Some more details about the device:
Android: 4.3
Manufacturer: Samsung
Model: GT-I9300
And finally, here is the crash log:
java.lang.IllegalStateException: Fatal Exception thrown on Scheduler.Worker thread.
at rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:62)
at android.os.Handler.handleCallback(Handler.java:730)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:176)
at android.app.ActivityThread.main(ActivityThread.java:5419)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1046)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:862)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: "/data/data/path/files/libopenh264.so" has bad ELF magic
at java.lang.Runtime.load(Runtime.java:330)
at java.lang.System.load(System.java:511)
at path.BeatMarker.init(BeatMarker.java:33)
at path.fragments.main.MainFragment.onOpenH264Done(MainFragment.java:475)
at path.fragments.main.MainPresenterImpl.onOpenH264Done(MainPresenterImpl.java:25)
at path.fragments.main.MainLoaderImpl$1.onCompleted(MainLoaderImpl.java:61)
at rx.observers.SafeSubscriber.onCompleted(SafeSubscriber.java:81)
at rx.internal.operators.OperatorObserveOn$ObserveOnSubscriber.pollQueue(OperatorObserveOn.java:201)
at rx.internal.operators.OperatorObserveOn$ObserveOnSubscriber$2.call(OperatorObserveOn.java:170)
at rx.internal.schedulers.ScheduledAction.run(ScheduledAction.java:55)
... 9 more
I'm pretty sure, the crash happens here:
at path.BeatMarker.init(BeatMarker.java:33)
These are the lines:
File libOpenH264File = new File(context.getFilesDir(), "libopenh264.so");
System.load(libOpenH264File.getAbsolutePath()); //line 33
Gets called, when the download and unzip is completed.
Can the error occur, while the lib is downloading and the network connection get lost?
Any help or hint is welcome, thanks in advance! :)
I have some problems with my Native Activity application. It works fine on 99% of devices. But sometimes users get the following error:
java.lang.RuntimeException: Unable to start activity ComponentInfo{nightradio.sunvox/nightradio.sunvox.MyNativeActivity}:
java.lang.IllegalArgumentException: Unable to find native library: sundog
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2070)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2095)
at android.app.ActivityThread.access$600(ActivityThread.java:134)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1203)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4830)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:789)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:556)
at dalvik.system.NativeStart.main(Native Method)
...
I can't understand why. The app have all necessary libraries in the armeabi, armeabi-v7a and x86 folders. And it has been tested on many devices with different architectures.
android:hasCode="true" option exists.
Also i noticed, that the most of these problematic devices has Rockchip CPU (RK3066, RK2928, RK2926). But not all. The latest one has Huawei K3V2 CPU and a lot of free memory.
Another Native Activity apps (not mine) don't work on the latest device too.
You will need to read the logcat output to see what happened prior to the crash, which prevented the native library from loading. I use Acra for my apps (generates crash reports containing logcat output), but as a quick solution to get the logcat output without implementing a whole crash reporting system, you could use something like this in a test build, and have the user run it:
try
{
Process process = Runtime.getRuntime().exec( "logcat -d" );
BufferedReader bufferedReader = new BufferedReader(
new InputStreamReader( process.getInputStream() ) );
StringBuilder log = new StringBuilder();
String line = "";
while( ( line = bufferedReader.readLine() ) != null ) {
log.append( line );
}
// Output available via log.toString().. do whatever with it
}
catch( IOException e ) {}
If you look at the source code for NativeActivty, this exception you are seeing gets thrown in the onCreate() method (see line 171), so if you override that method in a derived class of NativeActivity, you can catch it and grab the logcat output from there. Then you could save the log to a file and have a user with an affected device run the test and email the file to you, for example.
Another good thing about overriding onCreate(), is it will also allow you to reproduce some of what goes on behind the scenes, with more debug logging to help you track down the problem.
Some users have reported this error via the android error reporting popup thing but I have no idea what causes it. I googled but I can't find any good leads.
Anyone know what causes this error?
java.lang.RuntimeException: Unable to create BackupAgent
com.berlin.mobson.view.OsmandBackupAgent:
java.lang.NullPointerException at
android.app.ActivityThread.handleCreateBackupAgent(ActivityThread.java:2331)
at android.app.ActivityThread.access$2400(ActivityThread.java:134) at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1358)
at android.os.Handler.dispatchMessage(Handler.java:99) at
android.os.Looper.loop(Looper.java:137) at
android.app.ActivityThread.main(ActivityThread.java:4856) at
java.lang.reflect.Method.invokeNative(Native Method) at
java.lang.reflect.Method.invoke(Method.java:511) at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1007)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:774) at
dalvik.system.NativeStart.main(Native Method) Caused by:
java.lang.NullPointerException at
android.app.LoadedApk.initializeJavaContextClassLoader(LoadedApk.java:377)
at android.app.LoadedApk.getClassLoader(LoadedApk.java:320) at
android.app.ActivityThread.handleCreateBackupAgent(ActivityThread.java:2301)
... 10 more
My App is a Place finder that uses google Places api to get search results. (no the library, just the json urls)
osmand is
Mobile Map Viewing & Navigation for Offline and Online OSM Maps.
The source code is available here Osmand
May be you can remove osmand from the device and then debug the application using above code available.
Thanks
Looks like their BackupAgent implementation is having some problems. A temporary solution is unchecking "Back up my data" in settings->backup & reset. Long term the NPE has to be tracked down in the BackupAgent.
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.
Ok so i've installed everything that should be needed in order for APV and/or MuPDF to work, but it still crashes.
I'm not very good at using shells to install programs and all that, but i did follow the instructions included in the readme files as good as i was able to.
When i try to run the program now (APV) It works fine until i try to open a pdf file, where i get the errors:
FATAL EXCEPTION: main
java.lang.ExceptionInInitializerError
cx.hell.android.pdfview.OpenFileActivity.getPDF(OpenFileActivity.java:442)
cx.hell.android.pdfview.OpenFileActivity.startPDF(OpenFileActivity.java:403)
cx.hell.android.pdfview.OpenFileActivity.onCreate(OpenFileActivity.java:169)
android.app.Activity.performCreate(Activity.java:4465)
android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1049)
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1920)
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1981)
android.app.ActivityThread.access$600(ActivityThread.java:123)
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1147)
android.os.Handler.dispatchMessage(Handler.java:99)
android.app.ActivityThread.main(ActivityThread.java:4424)
java.lang.reflect.Method.invokeNative(Native Method)
java.lang.reflect.Method.invoke(Method.java:511)
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.UnsatisfiedLinkError: Couldn't load pdfview2: findLibrary returned null
java.lang.Runtime.loadLibrary(Runtime.java:365)
java.lang.System.loadLibrary(System.java:535) at cx.hell.android.pdfview.PDF.<clinit>(PDF.java:15)
I've installed everything in D:\Android , where i have the following subfolders:
apache-ant-1.8.3
android-ndk-r7c
android-sdk
Cygwin
apv (containing : pdfview\jni\ libraries like freetype, mupdf, jpeg, openjpg etc. also another version of android-ndk-r7c)
i've tried running all the build files included in the scrip documents like: build-native, scale-images, ndk-build![enter image description here][2]
This is a screen dump from build-native just before it finishes.
succesfull stuff happening
cp: cannot create regular file '../jni/freetype/include/freetype/config/ftoption.h': Permission denied
cp: cannot create regular file '../jni/freetype/include/freetype/config/sed008052': Permission denied
cp: cannot create regular file '../jni/freetype/include/freetype/config/sed007576': Permission denied
D:\Android\apv\pdfview\scripts\build-native.sh: line 31: gcc: command not found
D:\Android\apv\pdfview\scripts\build-native.sh: line 34: ../../scripts/fontdumpt: No such file or directory
I honestly have no idea how else to attack this and the tutorial at : http://mupdf.com/repos/mupdf/android/ReadMe.txt didn't do much for me. If anyone else have any experience using this then i'd really appreciate any help you could offer.
The application i'm making will be open source so by helping me you can get a good laugh at my code later on! :)
also, sorry for the shitty text but can't post images until i have 10 reputation
Thanks, Anders