Hey everyone, hope you are doing great. It's about a crash in android with BT v2 I have seen quite a lot of posts about this issue on this forum: getting a NullPointerException error making the app crash, when user stops using the app for a while (for ex 20 min) and then reopen the app. At this moment he gets a nasty "XXX has stopped working". It seems that @PJ got the error: http://www.buzztouch.com/forum/thread.php?tid=0A76562FDDBCDF85294205A&fid=79A3D47D59E2A7B06AB0970&sortColumn=FT.id&sortUpDown=DESC&currentPage=1 Also seems @Bigfishtools had it: http://www.buzztouch.com/forum/thread.php?tid=1E30F545526AE2DF6A9AD49&fid=79A3D47D59E2A7B06AB0970&sortColumn=FT.id&sortUpDown=DESC&currentPage=2 I have tried each solution suggested in the forum. I have seen @Northwest (thanks, by the way, for helping the community as you do) suggesting to remove background colors but it doesn't work. I actually don't use any of them, but a background image. Apparently it's about a method in BT_viewUtilities.java: updateBackgroundColorsForScreen. I have commented out the call to this method, then the method pointed by the logcat became getNavBarForScreen. I also commented out the call to this method, then the logcat indicated getJsonPropertyValue etc etc. I don't think it has anything to do with the content of these methods in BT_viewUtilities.java. Instead, I think it has to do with the call of the parameter this.screenData precisely when the user has not used the app for a while and attempts to reopen it. It's pretty bad because users are complaining about it on my app page on the play store and they regularly send me bug reports. I don't know what to do to fix it. I am no coder and don't know how the onpause, onresume work. Maybe we could try to refresh the value of this.screenData at these steps to avoid it being null and causing the NullPointerException? But how could we do that? Any help would be welcome

Hi @Don, Dang nullPointerException! Wish I had an answer, but I don't, so I'll sit back and wait for somebody smarter than me to provide one! Thanks for the props, by the way! Mark

Ah! I clicked feverishly on my email link saying there was a new reponse in this thread, ready to find THE ultimate bug fix but... ah! Just kidding :) More seriously, thanks for your support Mark, it's good to feel I am not alone in this fight! Would be freakin awesome if @David could post an update on this bug. I am wondering if this is something you guys are trying to fix, or maybe consider not high priority etc. BT is an awesome freemium service so there is no reason we should complain about it but... this bug is so painful!! And it seems it has been fairly precisely narrowed down (seems to me at least). Hope anybody has any info on it! Have a good day all Don

@Don: This is for sure something that's eluded us for a very long time. I usually try to avoid getting emails full of LogCat output (it's crazy long sometimes) but FOR SURE would LOVE to get a copy of your LogCat's output when this occurs. I'm crazy motivated to get this figured out and fixed once and for all. I've been hard-core Android all week long and don't see any sense it giving up now! LOL. Email me your LogCat, include a URL to this thread in your email. No sleep until it's finally found! Ha.

All right! I can see you got the Android fever David :) Ready to annihilate bugs! Seriously, thanks for giving a try! I am gonna try to differentiate below what is fact and what is assumption: So, my application usually crashes when: - it hasn't been used for a while (about 20 to 30 minutes), and then reopened. - it has been opened, then several other apps have been opened, then app is reopened Crash popup message: Unfortunately, <appname> has stopped working Also, several of these crash messages can popup one after the other as I touch the ok button (already had a dozen in a row). Assumption: My guess is the number of these popups approximately corresponds to the number of screens that have been opened in the first use of the app before the app was reopened and crash Logcat error: 10-16 14:00:59.578: E/AndroidRuntime(11677): FATAL EXCEPTION: main 10-16 14:00:59.578: E/AndroidRuntime(11677): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.messagesdamourlite/com.messagesdamour.BT_screen_menuButtons}: java.lang.NullPointerException 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2059) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2084) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.ActivityThread.access$600(ActivityThread.java:130) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1195) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.os.Handler.dispatchMessage(Handler.java:99) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.os.Looper.loop(Looper.java:137) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.ActivityThread.main(ActivityThread.java:4745) 10-16 14:00:59.578: E/AndroidRuntime(11677): at java.lang.reflect.Method.invokeNative(Native Method) 10-16 14:00:59.578: E/AndroidRuntime(11677): at java.lang.reflect.Method.invoke(Method.java:511) 10-16 14:00:59.578: E/AndroidRuntime(11677): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786) 10-16 14:00:59.578: E/AndroidRuntime(11677): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553) 10-16 14:00:59.578: E/AndroidRuntime(11677): at dalvik.system.NativeStart.main(Native Method) 10-16 14:00:59.578: E/AndroidRuntime(11677): Caused by: java.lang.NullPointerException 10-16 14:00:59.578: E/AndroidRuntime(11677): at com.messagesdamour.BT_viewUtilities.updateBackgroundColorsForScreen(BT_viewUtilities.java:41) 10-16 14:00:59.578: E/AndroidRuntime(11677): at com.messagesdamour.BT_screen_menuButtons.onCreate(BT_screen_menuButtons.java:126) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.Activity.performCreate(Activity.java:5008) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1079) 10-16 14:00:59.578: E/AndroidRuntime(11677): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2023) 10-16 14:00:59.578: E/AndroidRuntime(11677): ... 11 more I think the following: "Caused by: java.lang.NullPointerException 10-16 14:00:59.578: E/AndroidRuntime(11677): at com.messagesdamour.BT_viewUtilities.updateBackgroundColorsForScreen(BT_viewUtilities.java:41)" is key here as this method (updateBackgroundColorsForScreen) is called in all of my screens at the beginning of public void onCreate(Bundle savedInstanceState){ Tests I have done: Because it looks like the updateBackgroundColorsForScreen method is the source of the error, I have commented out the line calling it: //BT_viewUtilities.updateBackgroundColorsForScreen(this, this.screenData); After that, the logcat became : <same stuff> Caused by: java.lang.NullPointerException at com.messagesdamour.BT_viewUtilities.getNavBarForScreen(BT_viewUtilities.java:82) <same stuff> So now it looked the getNavBarForScreen method was causing the bug. So I commented again the call to this method: //LinearLayout navBar = BT_viewUtilities.getNavBarForScreen(this, this.screenData); and the logcat then pointed out this method: getJsonPropertyValue So, it seems to me these methods are actually not the problem. Rather, it looks like one of the parameters that are passed that is causing the crash. Each of these methods use the parameter this.screenData, so I think for some reason it has the value null when the app is reopened after inactivity and causes the nullpointerexception. As far as I understand it, maybe the solution could be trying to refresh this parameter somehow, to avoid it being null when app is reopened. But I don't know how. Does it has anything to do with onPause, onResume, onStop ? I am not sure how these work. Anyway, sorry for the long post, sorry I can not edit the layout so you can read it more easily. Obviously I am happy if I can provide more details. Thanks A LOT for having a look at this!

Encountering the same problem. Pretty much the same logcat as above. Some additional info... Using a button grid menu as home screen causes a force close immediately on opening the app (also grid menu with tabs). Using a simple list menu allows the app to open but causes it to force close at seemingly random times with pretty much the same logcat output. Immediately before the force close and logcat error messaging, logcat shows some bt debugging: 10-22 16:20:08.221: W/ZZ(9164): BT_fileManager:deleteFile 45456BA50548F65062ABF87_screenData.txt 10-22 16:20:08.221: W/ZZ(9164): BT_fileManager:deleteFile 45456BA50548F65062ABF87_screenData.txt does not exist 45456BA50548F65062ABF87 being the home screen id.

Thanks for sharing this Raveyd. Reinforces my assumption towards the source of the problem being screendata with a "null" value when screen is being loaded. Hopefully David had some time to have a look into it, finger crossed!

I've just done a bunch of commenting out which has successfully got the app open (with a grid menu) and remaining open. Unfortunately the menu screens aren't showing any content! It's progress though! Soooo.... Uncommented debugger and code in the BT_fileManager: //deletes one cached file... public static void deleteFile(String fileName){ BT_debugger.showIt(objectName + ":deleteFile " + fileName); File file = appname_appDelegate.getApplication().getFileStreamPath(fileName); if(file.exists()){ BT_debugger.showIt(objectName + ":deleteFile deleting " + fileName); file.delete(); }else{ BT_debugger.showIt(objectName + ":deleteFile " + fileName + " does not exist"); } } Which in my set up causes errors in: BT_activity_root BT_screen_menuButtons BT_screen_menuListSimple BT_screen_quiz So uncomment the code in the files showing the error: BT_activity_root: BT_debugger.showIt(activityName + ":loadAppData BT_config.txt file does not use a dataURL for remote updates..."); BT_fileManager.deleteFile(cachedConfigDataFileName); checkForCachedData = false; BT_screen_menuButtons: //init properties for JSON data... childItems = new ArrayList<BT_item>(); dataURL = BT_strings.getJsonPropertyValue(this.screenData.getJsonObject(), "dataURL", ""); saveAsFileName = this.screenData.getItemId() + "_screenData.txt"; if(dataURL.length() < 1) BT_fileManager.deleteFile(saveAsFileName); BT_screen_menuListSimple: init properties for JSON data... childItems = new ArrayList<BT_item>(); dataURL = BT_strings.getJsonPropertyValue(this.screenData.getJsonObject(), "dataURL", ""); saveAsFileName = this.screenData.getItemId() + "_screenData.txt"; if(dataURL.length() < 1) BT_fileManager.deleteFile(saveAsFileName); BT_screen_quiz: //init child items array... childItems = new ArrayList<BT_item>(); dataURL = BT_strings.getJsonPropertyValue(this.screenData.getJsonObject(), "dataURL", ""); saveAsFileName = this.screenData.getItemId() + "_screenData.txt"; if(dataURL.length() < 1) BT_fileManager.deleteFile(saveAsFileName); As I say, commenting those out gives a clean build and seems to fix the force close issue, but there's no menu data showing. So to me, the problem would seem to be somewhere in the code above...

To narrow it down further, the errors seem to revolve around the below and similar: if(dataURL.length() < 1) BT_fileManager.deleteFile(saveAsFileName);

App's still open, 15 mins and counting...

Following on from commenting out the code above, testing a line at a time has ended up with the same line in two files. Really hope this helps, it's taken hours! Testing on phones, Android v4.0.1 runs ok as is. Android v2.2.1 has the problems. The line is: saveAsFileName = this.screenData.getItemId() + "_screenData.txt"; in: BT_screen_menuButtons.java (around line 141) and: BT_screen_menuListSimple.java (around line 128) Various environments, consistent results: ---------------------------- Tabbed Layout - Home screen is menu buttons in a grid.. Commenting out both lines, tabs are ok, but no items in the menu - NO force close. Uncommenting both lines - immediate force close. menuListSimple commented out/menuButtons uncommented - Immediate force close. menuListSimple uncommented/menuButtons commented out - tabs are ok, but no items in the menu - NO force close. ---------------------------- Non Tabbed Layout - Home screen is menu buttons in a grid. Same as above. ---------------------------- Non Tabbed Layout - Simple Menu. Both lines uncommented - App force closes after a while (1 to 3 minutes). Both lines commented out - NO force close, but no data. menuListSimple commented out/menuButtons uncommented - NO force close, no menu data. menuListSimple uncommented/menuButtons commented out - App force closes after a while (1 to 3 minutes). ---------------------------- Tabbed Layout - Simple menu is home. Both commented out - Tabs ok, no menu data NO force close. Both uncommented - Tabs ok, Menu data ok, App force closes after a while (1 to 3 minutes). menuListSimple uncommented/menuButtons commented out - Loads ok, App force closes after a while (1 to 3 minutes). menuListSimple commented out/menuButtons uncommented - Tabs ok, no menu data, NO force close. Pleeeeease let this help! :)

"it's taken hours!" So feel your pain and APPRECIATE this effort immensely. I spent a ton of time this weekend coming to some of the same conclusions you have. I'll be re-visiting this yet again after today's webinars, fingers crossed. At this point you can probably stop pulling your hair out (unless of course you love it, lol) until I post another comment here. No sense in both of us pounding our fists on the desk :-) d.

<< No hair left David! Happy you're on the case :) I was wondering why it was fine on a newer phone, but I guess the bug's still there but the newer os has better bug trapping and can deal with it?

Had a quick play with emulators. Could only check two as the emulator takes far too long to fire up :( Google api set to highest level (14 or 16?????) Manifest set to use api level 8 - Emulator level 8 - App won't open at all. Manifest set to use api level 10 - Emulator level 10 - App works fine. Don't know how it might make a difference, but I noticed there's a bunch of depracated code in menuButtons and menuListSimple.. Much more than in other files..

Is there any progress on this?

Was wondering the same thing, any news on this topic? I would love to have a batdave signal and be able to point it towards the moon right now :)

I'm wondering why only a handful of people have reported it? Are people not testing their apps? Or is it only happening in certain circumstances? Or have people just given up and resorted to using basic list menus?

@raveyd, @don, and everyone else following this epic tale! I'm not 100% sure what's happening here but did make a change to the BT_screen_menuListSimple.java and BT_screen_menuButtons.java files. I've been focussing on these files to try to nail down what @raveyd diagnosed (a few posts above here). He worked a tons on this for hours and it's logical that he's on to something. Anyway, both of these files are doing the exact same thing where he reports commenting them out "fixes" or "removes" the crash syptom. Both files do: saveAsFileName = this.screenData.getItemId() + "_screenData.txt"; The button screen does this on line 141, the list is 126 (some editors are +- a few line numbers). This is a super simple method called. In English it's "Hey Android, set the value of hte saveAsFileName class variable to whatever your screen id is from the JSON plus _screenData.txt" Simple string concatenation here. No biggie. But, @raveyd isolated and commented out these lines and prevented some crashes. So, another approach to accomplish the same thing (append the screen's id to the name of the data file of the screen) is this: saveAsFileName = BT_strings.getJsonPropertyValue(this.screenData.getJsonObject(), "itemId", "") + "_screenData.txt"; Go ahead and replace both of those lines in each of those files. Cut / Paste, they are both doing the same thing. Or, you could always re-download the package, both of these files have been changed (only this one line) The craziest part...I cannot get any emulators, or devices. to behave the way it's described in this post / thread. And, to make this even more fun, there are literally dozens of screen types that use the previous method - seemingly with no problems. Lastly: There are a few warnings in the project if I bump up the Android Level to 15 or 16. Most of these are related to deprecated methods in Android 4.0 > Example: LayoutParams "fill parent" is deprecated and is now "match parent" - a few more examples of these sorts of changes. Not surprising, we're always chasing these changes and for sure they are not related ot the crash symptom. Build for Google API's 2.2 See if changing those lines fixes anything...report your findings. I'll be stoked (and surprised) if anything changes but we need to start somewhere eh? After days and days of TONS of source code scouring, I can't find anything else at this point. If it's still crashing we'll continue down the trail....

Thanks David! Dazed and confused now though... I have two apps. One with a home screen of a grid menu and tabbed layout, One just with a grid menu as home screen. I applied the changes to both. The app with just the grid menu now appears to be ok :) The other app still force closes as usual. So I removed the tabbed layout, downloaded the project with the changes but still get the force close! So I've created a test app with a grid menu and a couple of buttons - customURL and share by email and this doesn't force close, even without the code changes. I think I'm going to try and build a replica of the tabbed layout app and test it a screen and setting at a time, see what happens...

Hi guys, David: thanks a lot for your update! However, having a good deep read of your and Raveyd last answers, I think you have dealt with a different problem than the one I was initially reporting in this thread :) No bad intent at all, as it looked connected, but actually I am not sure anymore it really is connected. so, David, really to bug you again, but I would really be grateful if you could have a look at the initial problem This problem has also been reported by other BT user: @PJ: http://www.buzztouch.com/forum/thread.php?tid=0A76562FDDBCDF85294205A&fid=79A3D47D59E2A7B06AB0970&sortColumn=FT.id&sortUpDown=DESC&currentPage=1 and and @Bigfishtools: http://www.buzztouch.com/forum/thread.php?tid=1E30F545526AE2DF6A9AD49&fid=79A3D47D59E2A7B06AB0970&sortColumn=FT.id&sortUpDown=DESC&currentPage=2 I have detailed the tests I have done in the post #5 of this thread. To sum up, apparently it has to do with the parameter this.screenData when these methods are called: BT_viewUtilities.updateBackgroundColorsForScreen(this, this.screenData); or LinearLayout navBar = BT_viewUtilities.getNavBarForScreen(this, this.screenData); David do you have any idea of why this is causing the app to crash?

Think I might have it... Apps running ok now. In the Button Size options of the menu, if the button size + margin combination is larger than the device/emulator width it causes a force close. If the button size + margin combination is changed to be less than the width, the config file is updated, but even if the new config data is pasted into the eclipse project and the app run again, it still force closes. The app needs to be uninstalled from device/emulator, then run the app again for the changes to take effect. The problem I have now is that my newer device has quite a large screen but is still classed as a small device, so the buttons are too tiny to be of any use, but perfect on my older phone, and when the buttons are a good size on my newer phone they force close my old phone! *edit - sorry Don, I thought they were related..

The adventure continues. I too agree that this is NOT related to the way the cached file name is / was being created. I made those adjustments after learning that "commenting them out" prevented a crash" No worries, not related. Next, button screens; I'm also not convinced that the button screen has anything to do with this. I say this because the width / layout / margin stuff has zero to do with Android's ability to manage memory, "nullPointerExcpetions" etc. I'm 100% convinced that this is the same issue that's been eluding all of us for a long time, the BT_viewUtilities.updateBackgroundColorsForScreen(this, this.screenData); method call on each screen is killing the app in some situations. Not all, almost never actually, but sometimes (depending on tons and tons of factors). To confirm this, comment out that line on all the screens that are loading as your home screen. This will be one screen in a non-tabbed app, up to 5 in a tabbed app. If commenting that line out prevents the crash, we know this is the issue (the same issue that nobody has figured out yet). Comment them out...test...post results here, bet it doesn't crash if we do NOT call this method; BT_viewUtilities.updateBackgroundColorsForScreen(this, this.screenData); So, if your home screen is a BT_screen_menuButton.java class file, line 122 will become; //BT_viewUtilities.updateBackgroundColorsForScreen(this, this.screenData); All you're doing is telling the app to NOT update it's background color for that type of screen. If this prevents the crash, we'll need to once again dig into the actual updateBackgroundColorsForScreen method in the BT_viewUtilities.java file (feel free to have a look at it).

Ok, it's nothing to do with memory management, BUT, I've been testing all afternoon and it's absolutely 100% consistent. Buttons+margins too large - NullPointerException. Buttons+margins sized ok, app runs ok. I've just tried making the buttons larger and commenting out line 122 as above and get the NullPointerException in BT_screen_MenuButtons again. Making the buttons smaller and either commenting or not commenting line 122 and the app runs ok.

@Raveyd: absolutely no need to be sorry man, I am actually glad you have identified your bug and made progress, that's all positive stuff :) @David: thanks for keeping on fighting the devil bugs in this epic journey :) Here are the tests I have done: My first screen is a button grid Log error after crash <blah> Caused by: java.lang.NullPointerException 10-16 14:00:59.578: E/AndroidRuntime(11677): at com.<myappname>.BT_viewUtilities.updateBackgroundColorsForScreen(BT_viewUtilities.java:41) I have commented out: //BT_viewUtilities.updateBackgroundColorsForScreen(this, this.screenData); After that, the logcat pointed out: <blah> Caused by: java.lang.NullPointerException at com.<myappname>.BT_viewUtilities.getNavBarForScreen(BT_viewUtilities.java:82) <blah> So now it looked the getNavBarForScreen method was causing the bug. So I commented out again the call to this method: //LinearLayout navBar = BT_viewUtilities.getNavBarForScreen(this, this.screenData); Then the logcat pointed out this method: getJsonPropertyValue It seems to me the logcat will always point out the call to a method using the parameter this.screenData This parameter gets the value null when the app is reopened after inactivity and causes the nullpointerexception crash I am no expert, but maybe the solution could be trying to refresh this parameter somehow, each time app is reopen, to avoid it being null when app is reopened?

@Don: Awesome, this info looks very promising. I agree that it's looking like the "null" object (the object we are looking for) must be the screenData (JSON) for the current screen. I've stepped away from desk but will dig into this when I return. "Professor Plum did it in the Living Room with a Candlestick" Clue, my favorite game ever!

Haha, good reference :)fixing bugs as a metaphore of playing a board game, great idea to keep the spirit up! Back to the issue, for what it's worth, I was wondering if the paragraphs on each screen "onResume()" or "onPause()" or even "onStop()" could be of any help? The solution might be to get this parameter this.screenData refreshed when the app is reopen after inactivity. I will keep on trying on my side too.

@don and @raveyd: Can you email me a copy of the exact config.txt JSON data you're app's are using. I feel like we've isolated this to the getNavBarForScreen() method and to the idea that the screen's screenData property is null but I can't duplicate the darned thing. Can't get it to crash! I'm running into the same thing I've ran into before when trying to figure this out - it works! Ha. Figured I would create an exact duplicate of you're JSON and go from there. a) Send the JSON to david 'at' buzztouch.com b) Include any details about the device you're using, the emulator, Android version, etc.

Thanks David, I have emailed you my config file

I seem to be late to the game here but I am having the same issue. I don't have an android device myself... seems to be okay on the emulator but users keep complaining. The only screens I use are simple menu lists and html. That's it. I can also send my config.txt file if that will help. Good luck everyone!! Getting close to bailing on android altogether. Thanks... Josh

Looks like we've finally got this! https://www.buzztouch.com/forum/thread.php?tid=8B5CBFBAAAA9373BB96B9E7