Android fans... We've been struggling with a crazy-to-find NullPointerException error when running Android apps on newer devices. This was occurring "sometimes" on devices running Android 4.0 or higher. Dont' confuse this with the API level your project is compiled for. You should be compiling with Google 2.2 API's (not Android 2.2 API's). That hasn't changed. What did change: Two files, both in the Core files so no changes are needed to any Android plugin class files. --BT_act_controller.java: This is the file that's used to "load new screens" on button taps and other events. The loadScreenObject method has been updated. This method begins on line 91 of this file. --BT_act_base.java: This file has changed and some logic has been added in the onCreate method. You'll see this newly added logic on line's 128 through 146 of this file. Technical details for nerds and code ninjas like me: Every screen in your app relies on an object called screenData. You'll see this through nearly all the plugin .java files. It's usually references like: this.screenData. The variable (sometimes called a field, property, instance variable) holds the JSON data for the screen that's being displayed. It's important for the code to know the value of the JSON data for each screen so it can fix-up the background color, image, nav bar, and other miscellaneous properties each plugin needs. This is the data you setup in the config.txt file (using the control panel in most cases). The NullPointerException trouble was happening when the app was pushed to the background (in most cases, it happened in other strange cases too) and the reference to the screenData was lost. When the app was brought to the forefront, and the current Activities onResume method fired, it looked for the screenData object - IT DIDN'T EXIST and was null. This is the issue. The fix was to implement a different method to SET this value. Before these changes, the screenData for each screen was "remembered" in the global values for the app. This was not working. When each new screen loaded it was looking for this "remembered" value. Now, with the newly created logic, the loadScreenObject routine (in the BT_act_controller.java file) "passes along a payload" holding the JSON data for the next screen. If you're unsure what this means, it's worth reading up on? You tap a menu item, the BT_act_controller.java file loads the next screen, in doing this it passes along the screenData payload so the "next screen" has a reference to it. We've tested this on a ton of devices and it's looking like this newly implemented logic got rid of the NullPointerException troubles. Correct us if we're wrong :-) Off to the next item on the giant list of lingering improvements.....

Excellent! Thanks David :) :) :)

Yeah baby!

Fingers crossed! LOL

David you rock! That's awesome, I will try the fix asap, hopefully tomorrow. With the description you wrote, it should definitely solve the issue, as the diagnosis you have identified seems exactly like what I have seen too (yours is better explained though :) Thanks A LOT for all the time you spent on this. It is definitely worth it, as this bug was causing crash causing users to post negative reviews, impacting ranking. Thanks again

FANTASTIC!

Getting errors to go away is always a good thing... Just something I learned sometime ago when getting one of my apps to save persistent data to maintain screen display consistency (instance state): Pushing the home button, pauses the activity. When you come back the app is restarted. IF you hit the back button a different behavior, the app is destroyed. The only way I figured it out was putting tags on all the OnDestroyed, OnPause methods and so on. I see that in any case, Either onPause or onResume was always called. So basically doing something in either of the 2 cases usually covers you.. Example below if it shows up.. How to add logs to your methods. and of course you have to import android.util.Log; @Override protected void onStop() { // TODO Auto-generated method stub super.onStop(); Log.v(TAG, "onStop()"); }

This is sweet...

@Zoid66 is back! LOL. Totally agree. One of the most frustrating parts of Android is the seemingly inconsistent order in wich an Activities LifeCycle Events are processed / triggered. There literally is NO logical reason for them to behave inconsistently. Example: Start an app on Android 4.0 >. Click around a bit (with your LogCat statements in all the onCreate, onPause, onResume, onDestroy, onStart methods) and note the Lilfecycle event "order." Kill the app. Remove it from your device. Do the same thing again, same app....totally different result! Ugh. And, to make matters worse, different versions of Android process these events at different times. I know all the mumbo-jumbo about "your app needs to be prepared for these events" but that's not the point. Another example: "start an Activity" in Android < 4.0 (lower than 4.0) and monitor the onDestroy method for the previously displayed Activity. It never gets called. This makes perfect sense. Why destroy an Activity when you are very VERY likely to come right back to it. And, there are only two Activities in the stack in this example. Makes NO sense to kill the first one. Do the same thing in Android 4.0 >. Leave an Activity by starting a new one, it gets killed, destroyed, done, bye bye. Why? To save battery? To save ink? To save pixels from burning out on that fancy screen? I don't get it. Makes no sense. How can destroying the ONLY Activity that was running (besides the newly displayed one) do any possible good at all? Pressing back forces Android to re-create the thing every single time. The savedInstance state, the thing that was supposed to "remember" the state of the previous screen (like all the selected checkboxes, or the currently selected row on a list, or the status of the play button on your song, etc, etc) is GONE, vanished, see ya. Looks like the savedInstance state idea is just as inconsistent as the Lifecylcle Events. Oh, wait, I'm supposed to "remember" the state of the previous screen because I'm a developer - my bad. I'll be sure to do that! Ha! I guess I could grab the current Context, snap a picture of it, save it to memory (must have a ton since everything's getting killed!) and staple it to the phone's cache for a few minutes. Then, when the user "comes back" I could quickly trick them by showing them the previously saved bitmap while I recreated a crazy complicated UI again. LOL, sounds funny when explained this way. I'm NOT ranting about Android, I'm ranting about all the different approaches that manufacturers have taken to extend Android. I sure hope Google gets a grip on this or it's going to make the browser wars and inconsistencies of the mid 90's look like child's play. Oh, wait, Android is open source, Google can't get a grip on this thing, even if they want to. I'm flashing on tons of buzztouch control panel installs that are broken, super ugly, and simply not worth using. These are the ones that folks have "improved" because our "basic layout and functionality" wasn't good enough...or so it appears. Maybe Google can call them for us and explain the fragmentation idea. Open source...gotta love it...gotta hate it....GO ANDROID!!! d.

I am feeling the pain as well.. Just as I thought I got most of my issues behind me here comes Jelly Bean! Android 4.1 (Most people are using some port of 4.1 unofficial) And the emails roll in with issues. The great part is trying to find out what is broke as the Virtual Devices is clean as can be. -- Love to hate it! Off to best buy or some store trying to 'borrow' a devices to see what the heck people are talking about only to see hum 4.1 no issue on this devices.. lol I have went through the Activities LifeCycle Events page for Android so many times. Then in the end I say okay, I am doing all correct for now.. Scratch my head.. Move on and some devices leave behind for now.

So is this in the code base and we just need to redownload and recompile or do we have to go and try to figure out the fix ourselfs? As someone who has seen this for a long time GREAT NEWS!