Last year I tried to release this app on BT3, but I had reports of it crashing on Samsung devices. I've also heard of people having problems with nexus devices. I would like to know if this version is stable, but I only have one old tablet. So I'm reaching out to anyone to please give this app a try please and see if it runs. Link for app : https://db.tt/6y0GngnL I'll leave the app there for about 48 hours. Please let me know if it crashes! Many thanks in advance, Alan

Hi Alan, confirm this crashes on my Samsung S3 (Android 4.3). I note that the logcat is showing the same errors I get when using Push on android (with Samsung) in that it is complaining it requires: android:name="android.permission.INTERACT_ACROSS_USERS_FULL" I add that permission in the manifest in the uses-permission bit, under the last entry on GSM (near the top of the manifest) - that always sorts it on Samsung. <uses-permission android:name="android.permission.INTERACT_ACROSS_USERS_FULL" /> Also, I "believe" it is moaning about READ_PHONE_STATE permission as well. If you want to add those two perms and repackage, Im happy to test of course. Regards Rob.

Hey Alan, just install Genymotion and you can test that yourself! Really the way to go if you want to test your app on different devices and operating systems!

Just ran fine on my Nexus 7. I went through all screens and everything worked, nice looking app! Thanks Leon for the Genymotion mention, I need to test on more devices too. I found Appthwack a couple weeks ago, and they are fantastic, but give you 100 test-minutes for free, then its pay time.

Rob, thanks for those tips, I have incorporated them (I had in fact removed the phone state permission) and updated my dropbox with the latest. Looking forward to the re-test, fingers crossed! LeonG, that is good advice, I am already a convert: http://www.buzztouch.com/forum/thread.php?tid=6C14DF2E59572EF1D131126&sortColumn=FT.id&sortUpDown=DESC&currentPage=3 I even downloaded the latest update yesterday. On this particular issue, I found another update that made a difference and when I tested with genymotion. I added the line: android:largeHeap="true" Which seemed to make things better on the simulator, but I always think the ultimate test is the real device. RonBo, thanks for testing it, glad to know the nexus ran my app - is yours running android version 5? If anyone else would like to give it a go please, it will raise my confidence levels. Many thanks for your time, it is appreciated. Alan

Hi Alan, Similar results for me I'm afraid - crashed on start. Still complaining about interact permission but also seems to be running out of memory too. Dropbox link of logcat output is below - how big are your images as I wonder if compressing them may help? https://www.dropbox.com/s/23tj8b8k9hz9zx5/log.txt?dl=0 Regards Rob.

Thanks for retesting Rob. The crazy thing about this problem is that the same app can run as BT2, with the same images. I have optimised them, next step is to remove some of them. I will take a closer look. Stand by...

Yes, running Android 5.0.2, Kernel version 3.4.0-g154bef4 One thing to check: on your android, go to Settings, Apps, pick Running along top, Show Cached Processes. Keep an eye on your app as you go in and out of each other screen. It slow creeps up in cached memory pretty high, and you'll see that it never gets back down to it's fresh-start level of cached memory. Not sure if this is a memory leak or just the way cached memory works...but my BT 3.0 Android App always ends up having the highest cached memory on my device. Maybe a separate thread on garbage collection / memory collection is in order?

I have not tried the app, I don't have time right now but here is a tip that stopped my app from crashing. make sure the header image if any is not being pulled from the control panel. Sue and I worked through this last week or so and once I placed the image in the app all was well. Just a possibility in case you have not tried it Joe Sprott Bodacious Media

Through trial and error I also found that to be true!

Hi guys, thanks for all the feedback. I use the CR advanced menu on my home page, it does use a banner, but it is already in the project, but it was a good thought. I just updated my Eclipse environment, suffered a bit of a breakage in the process. Took a few hours to fix, but I am back up and running again. My app uses a lot of background images in the quotes section and I have just halved that. The app runs in the very latest Genymotion Samsung Galaxy S3 - 4.3, so I am hopeful. Link for app as before is: https://db.tt/6y0GngnL My biggest problem at the moment is I cannot reproduce the problem for myself, so I really appreciate all the help.

I would be grateful for more testing please, especially if you have a Samsung, as that is always where the problems have been. Thanks, Alan

Hi Alan, installed your latest on my S3 again - although apk is smaller it still crashes on launch im afraid. Ive reset my mobile several times just in case and still the same with this version for me.

Hmm, back to the drawing board. Thanks for doing the test Rob. I think your logcat told me java ran out of memory and I thought having too many graphics was the issue. I'll look more closely at logcat in the morning and go again. Cheers, Alan

Check out apthwack.com You get quite a bit of free testing on devices of your choosing. They provide logvat output and screenshots from every device you test on

It is almost never about the device, but about the operating system! Pretty sure Rburns has a different OS than your genymotion 4.3!

Hi @AlanMac (and others)... Not sure where this stands (I'm about a day behind). This absolutly sounds like a memory thing. Only say that because it almost always is when you have some devices OK, some not. My Nexus runs this without crashing but for sure the many of the menu items seem "sluggish." Meaning there's a delay between the time I them and the time they load. Hmm. I especially like the track maps. Good stuff. The could background art would be eating some memory. Note: It looks like lots of the background art it the same graphic? Some difference but mostly the same. One of the major drawbacks of Android, as we all know, is how it processes Bitmaps and other images. Tons of work to be done on this, both in my code, and in Android itself. Not sure if that's what's killing your on some underpowered devices or not. Not sure how to help....other than maybe doing some background art adjustments, re-publishing, then seeing how it goes. Adjustments: You're likely NOT updating the background art very often, from the control panel. You could optimize the image sizes, include them in the layout.xml files manually (refer to the drawable right in the xml layout file) and NOT use the code or the BT logic to dynamically add / change the background art. This is for sure a memory hog in BT apps and any other apps that use this dynamic approach. So, hard code your background art in the xml (layout files) and see how it goes? Not sure what else to add

Thanks for the insight eveyone. I have made a bit of progress. First, I have found a genymotion emulator (Samsung Galaxy S4 - 4.4.4) that crashes with my app. Kudos to LeonG for pushing me down that road. Debugging is hard at the best of times, but if you can't reproduce the problem, it makes it that much hader. Next, I took on board David's thoughts about background art (I'm afraid the xml went over my head). I halved the number of background images again. They are all the same size jpg's and I shrunk them using an online utility. This will ultimately help performance, but it didn't help stability. But it made me think. I am not doing anything clever in java in this app. All the background art stuff is using custom url, html and javascript and the app crashes before I get to that. In fact, the app crashes before it loads the home screen! So looked at Leons logcat again. It shows that as soon as the home page tries to load its banner, that there is some significant memory related actvity - this extract shows it: 03-12 06:09:56.599: W/ZZ(3276): Cr_menu_advanced: header image exists in resources folder: "f1_banner1536x480.png" 03-12 06:09:57.439: D/dalvikvm(3276): GC_FOR_ALLOC freed 185K, 13% free 7592K/8680K, paused 327ms, total 352ms 03-12 06:09:58.627: I/dalvikvm-heap(3276): Grow heap (frag case) to 13.096MB for 5832012-byte allocation 03-12 06:09:58.659: D/dalvikvm(3276): GC_FOR_ALLOC freed 11K, 8% free 13276K/14376K, paused 29ms, total 30ms 03-12 06:09:58.803: D/dalvikvm(3276): GC_FOR_ALLOC freed <1K, 8% free 13276K/14376K, paused 31ms, total 31ms 03-12 06:10:00.323: I/dalvikvm-heap(3276): Grow heap (frag case) to 43.459MB for 31850508-byte allocation 03-12 06:10:00.359: D/dalvikvm(3276): GC_FOR_ALLOC freed 0K, 3% free 44380K/45484K, paused 36ms, total 36ms 03-12 06:10:00.375: D/dalvikvm(3276): GC_FOR_ALLOC freed 0K, 3% free 44380K/45484K, paused 19ms, total 19ms 03-12 06:10:01.743: I/dalvikvm-heap(3276): Grow heap (frag case) to 73.834MB for 31850508-byte allocation 03-12 06:10:01.803: D/dalvikvm(3276): GC_FOR_ALLOC freed 0K, 2% free 75484K/76592K, paused 58ms, total 58ms 03-12 06:10:01.899: D/dalvikvm(3276): GC_FOR_ALLOC freed 0K, 2% free 75484K/76592K, paused 43ms, total 43ms 03-12 06:10:01.899: I/dalvikvm-heap(3276): Forcing collection of SoftReferences for 31850508-byte allocation 03-12 06:10:02.035: D/dalvikvm(3276): GC_BEFORE_OOM freed 9K, 2% free 75475K/76592K, paused 135ms, total 135ms 03-12 06:10:02.035: E/dalvikvm-heap(3276): Out of memory on a 31850508-byte allocation. I believe this where where it runs out of memory and then we have an accident waiting to happen scenario. In mentioning header image, Joe Sprott and RonBo were onto something. I halved the size of the header image, but that didn't help. Then I just removed the header image file from my project and it runs. My conclusion based on this is that: - The problem happens in the CR Advanced menu (the home page) - Android runs out of memory - The problem is precipitated by the header image. There must be something about Samsung devices that provoke the problem to do with memory management? If so, I am not sure what I can do about it. Any suggestions?

Hi Alan, Nice detective work. I haven't used that particular menu so cant comment, but have never had an issue with other menu plugins options using a header image - even on my Samsung S3 (which is running stock 4.3 Android by the way)! Have you pursued a different main menu option?

Hi Alan, Just looking again at my logcats and yes, it looks to load your "f1_banner1536x480.png" image and then crashes out. As a quick test, also try renaming file name to something smaller like "f1bannermain.png" as I confess I have had issues with long names and the "_" character before now. And also copy that file to all the drawable folders too. Just a thought.

Not sure if this applies, Chris1 (the author CR menu advanced) does great work but a while back I had a number of Android apps crashing using the CR Menu Advanced menu, I changed them back to Susan's "Menu With Image" and it seemed to resolve the problem. This may NOT be your problem but probably worth a shot if the app isn't live. Just my 2 cents Cheers Darrel

This app (GP Race Fan) is live, in Google Play (using BT 2.0) and iTunes (usin BT 3.0). It is a combined app from one control panel entry with all the graphics built int to the project. The added complication is that making certain changes will affect the apple version and I've only just updated that in the App store. It relies on @Chris1's menu to know when to display Apple or Android specific screens and no other menu does that. The only fix I have found so far is to remove the banner altogether and I don't really like the look without it. I've sent a message to @Chris1 to have a look, so fingers crossed. It only goes wrong on Samsung devices, but then again, there are quite a few of them!

After my last post, my app didn't want to run on Genymotion, even without the header. So I started to think that maybe it was always on the edge of crashing. Based Darrel's 2 cents, I turned my attention to a test app that I have. It had menu simple as it's home page and I changed that to be CR advanced menu with image. It now crashes on my tablet, although not the same java error. It loads, then after some navigation, it just stops responding. Go back to menu simple, no issues. So it really feels like it has something to do with Advanced Menu with Image. Which is a pity, as it is one of my goto plugins. Over to you Chris?

Say, are you minimizing your images with tiny.png? Also, put them in all the drawable folders. Then, if that doesn't work, resize them proportionately in your drawable folders. I only needed to take that extra step in one app. I doubt it is the Menu Image Advanced plugin causing the problem, because the plugins are so similar. One thing the Menu Image Advanced has is multiple xml files for each scenario of whether an icon or description text is used. But that should make it more efficient than the Menu with Image, not less efficient. The Menu with Image is checking to see if an icon is there and moving over the text, whereas the Menu Image Advanced doesn't have to do that. http://developer.android.com/guide/practices/screens_support.html

Thanks for the idea Susan. I have tried putting the header image into the different res/drawable files and I have tried removing nearly all the images that are used in the background artwork. And I have tried jpg instead of png and back again. But I will try again, in a new incarnation of the app. When you say "an icon or description text" I presume you are referring to the menu row entries - I use both. The icon images are all in res/drawable - I could try those in the other ones too. These questions are the ones that I think could be the key: Why does it work without a image header image present? Why is it only Samsung devices? Why does it work in BT 2.0 but not 3.0?

Its a memory problem. My guess as to why it seems to be affecting Samsung devices is because there a lot more Samsung devices out in the wild with very high screen resolution. Also, they make modifications to the Google code, although Google is trying to reign that in. So, you tried the tiny.png on all the images? Here is another idea. Android keeps adding more drawable folders. They are up to "xxxhdpi (extra-extra-extra-high) ~640dpi". Try adding the xxxhdpi folder to your Android project, and see if that does the trick. I haven't had to do that yet, but it would be the next thing to try.

I have used tinypng on everything. I even used photoshop to reduce the colour depth on the header images to something horrible to make the images smaller. The only things that had any positive effect were to tell the menu plugin it has a header image but remove it, and add the largeheap statement for the manifest. Or compile with BT 2.0. I will stick with this, but I need to start it all up on a new project as I do not want to break the existing one. I am also going to start using Android Studio, gulp.

So I had to put this app down for a bit, but I went back to it this week. I rebuilt it completely from scratch and all was going really well until I tried the Samsung simulators again!!! However, as the rebuild is not published, I have been able to blunder around in the code and experiment. The problem is triggered by the background image and header images in the menu, the rest of my app seems to be OK. It doesn't seem to matter how small I make them, jpg or png, but if I removed them, my app worked. Then I found something out. To quote Android documentation: "For applications that support Android 1.6 (API level 4) and higher, this is "true" by default and you should not set it "false" unless you're absolutely certain that it's necessary for your application to work.” So I set android:anyDensity=“false”. (The default setting in the project is true). This setting appears to control whether android tries to resize your images. In my case, it appears that setting it to false *is* essential. It appears to allow my app to run on a Samsung and it does not seem to hurt anything else. If I understand correctly, setting to false has the exact same effect as copying all your graphics into all the the different res drawable folders, but obviously the app is easier to maintain this way and also does not increase the size of the app. Another important setting in the manifest is android:largeHeap="true” which definately helps. I might ask for a final test on real Samsung device please, just to be sure!

Nice discovery! Time to take the Mac off your avatar? ;-) For each of the different res drawable folders, did you initially have appropriately DPI and sized images?

I'll rerun on nexus7 if needed...

Thanks Ronbo, I will take you up on that. Just doing some more checks before I ask. Niraj, no, I didn't at first, but I started trying that. Frankly, it always seemed to be some kind of magic that seemed like a very cumbersome way to go about things and I didn't understand why it should work. On top of that, my BT 2.0 app never failed with the exact same images. And my app uses a lot of images (in a webview), but I now believe that only the images being used by the menu caused the problem. To prove my theory, all my images are back to just living in the basic res drawable folder and all is good. So far...

A side effect of setting android:anyDensity=“false” is that the action bar menu does not display correctly. On some devices it is completely off screen, on others partly off screen. It is a reported side effect in stackoverflow , but the only reported solution is is to put anyDensity back to true, is not much of a solution. Preventing Android to try and resize images is what I think stops the app crashing. looking at the logcat, the crash is always preceded by an attempt to free up some memory then load an image. If any density is set to false, my app never runs out of memory. When set to true and all the images in res drawable, it does not even load on some samsungs. If all the images are in all the res drawable folders, the app does less image resizing, but I have seen it crash eventually. My suspicion is that android crashes when it it resizes images, but it is designed to allow that. My belief is still that there is something more fundamental going on, maybe fragment memory management something or something to do with layouts, or not using "dip" everywhere. Fix that fundamental issue and the app should not crash with anyDensity="True". If only I knew enough about java to work that out...

Facebook launched a new tool (as noted by TechCrunch) "... Fresco, is a new image library for Android apps." "The idea here is to ensure that apps don’t run out of memory when they load multiple images by being smarter about memory management (those GIFs can get huge, after all) and streaming images when possible." https://code.facebook.com/posts/366199913563917/introducing-fresco-a-new-image-library-for-android/ http://techcrunch.com/2015/03/26/facebook-does-android-too/

Hi all I still think the problem is triggered by android trying to resize images and running out of memory. I've made some more tweaks to the app and I could do with some independent checking please? I have uploaded another version to try here: https://db.tt/IUmqM3eN Would you mind trying out this version please? If this does not work, I may have to stick with BT 2.0! Thanks, Alan