Debugging app crash?


I have a pair of apps that are very similar to two I’ve already created (and which are stable)… the only problem is, they’re randomly crashing. They only crash when I switch screens, so I think there’s something related to the typical reasons for this, but: my apps all open screens from Screen1, then return to Screen1 via a “Home” button that calls “close screen” (or a floating button in one case). This is exactly how the other two are set up, and yet, these two apps are crashing, and the others aren’t.

This is my final barrier to shoving them out the door, but I’m not sure how to proceed with identifying where the problem is. Help?!?

Copy data and blocks to an other screen
App FC after a while

@Thomas_Leavitt Please try to use ADB to see if you get info about crash issue:


my apps all open screens from Screen1, then return to Screen1 via a “Home” button that calls “close screen”

it seems to be, ýou are switching screens correctly…

did you upload large images into the assets of the app?
see tip2 here



Thanks. I got ADB installed on my Mac using the instructions at the URL below. Worked flawlessly, and was effortless.

Now I just need to walk through your tutorial. :slight_smile:


@Taifun - one of the unstable apps uses exactly the same fonts and images (minus a couple of background images) that the other two stable ones use. There’s a total of 6 images (backgrounds are slightly less than 1MB apiece, images are all under 100k apiece, app icon is 250k) and two fonts used in the app, plus an app icon. I really don’t think I’m doing anything unusual here in that respect.

Like I said, it crashed, and left a screen open at one point, which is behavior similar to what I saw before I started doing the “close screen” thing, and it’s only when I’m clicking around opening and closing screens that I trigger a crash.



11-01 03:06:56.853 19910 20042 E AndroidRuntime: FATAL EXCEPTION: Thread-23
11-01 03:06:56.853 19910 20042 E AndroidRuntime: Process: com.appybuilder.thomleavitt.HesiodWorksandDays, PID: 19910
11-01 03:06:56.853 19910 20042 E AndroidRuntime: java.lang.OutOfMemoryError: Failed to allocate a 47781516 byte allocation with 33554432 free bytes and 35MB until OOM

The is an LG V20. I have no idea what’s chewing up resources.

I did notice I was basically out of space on the device (592 MB free of 50+ GB). Ugh. Time to delete unused apps.


you might want to read again tip2 and follow the links there…
see also what @Italo once explained:

First, you need to understand that the file size of an image is not the amount of memory it uses when it’s being displayed. The file size is the compressed size, much like a zip or rar file. When viewed, the image needs to be decompressed.
For example, if your image says its file size is 100 kb, and its dimensions are 1024 x 768, 32 bit color, then that image uses over 3 mb of RAM (not 100 kb!) when you show it on the screen. ((1024 * 768 ) * 32) / 8 = 3,145,728 kb (3 mb)
Now, this is a mistake most people make when using arrangements as “virtual screens”: They set different image components with their images loaded but hidden, instead of having only one image component and changing the picture according to the user’s selection or app events, not knowing that apparently the hidden image components are also using the ram, (yes, even though they are invisible!).



Ehh… the app is trying to allocate 4.5GB of RAM. I’m thinking that I’m somehow triggering a memory leak in a loop. Going to go stare at my code and see if anything spontaneously reveals itself.


O.K. So, in the two crashing versions of the app, simply opening and closing each of the screens in sequence leads to a crash.

Here’s the app design, basically:

  • Screen1; on it are buttons for ScreenA, ScreenB, ScreenC, ScreenD
  1. ScreenA - has “Home” button that calls “close screen”
  2. ScreenB - has “Home” button that calls “close screen”
  3. ScreenC - has “Home” button that calls “close screen”, and floating button that does same
  4. ScreenD - has “Home” button that calls “close screen”

None of these Screens navigate to any other screen.

Open ScreenA, hit “Home” button, … Open ScreenD, “app crash”.
Open ScreenD, hit “Home” button, … Open ScreenA, “app crash”.

I can open and close three screens repeatedly, in any combination, perform associated activities, but as soon as the fourth screen is opened for the first time, “boom”.

O.K. I took it further… I ripped out every last bit of block logic other than the 4 buttons that call “open another screen” on Screen1, and the button(s) on each screen that call “close screen”, and the crash is still totally reproducible. W.T.F.?!? I didn’t bother to use ADB, as I’m sure the results are similar, but I’d be happy to do so. Did I miss something in the way the screens are being set up? … and what the heck could I possibly be doing with ZERO LOGIC other than the screen design, that would trigger a crash?


You may want to post your sample aia


Hmm… I deleted all the images from my “sample” app, and the fonts, and changed nothing else, and the crash goes away. Screencap of a file listing attached. The fonts are 184k and 120k in size. The buttons in the app each use one of the scroll images listed, each screen uses the hesiodback.png image as a background, the buttons use the fonts for the text, and one screen switches between the hesiodback.png and worksanddays.jpg as the background image. AIA with assets stripped out attached.

Test_copy.aia (8.8 KB)


Any feedback? I’m just not seeing how simply adding these relatively innocuously sized graphics yields 4.5GB of allocated memory and an app crash. A coder friend suggests that somehow, it’s all being rasterized, and cached, and my phone’s high resolution (LG V20) is triggering the problem as a result. Is there anything I can do to provide more info? I could have my wife make up blank versions of the graphics in question for folks to test with, if desired. The thing is really acting like I’m not closing screens even when I’m explicitly closing them, no other discernible reason that the crash is completely reproducible as mentioned, but doesn’t happen any other way.


@Thomas_Leavitt Starting to check into your sample. Sorry for delay :slight_smile:



Checking into your test .aia, it looks like you are correctly handling the screens and matches the recommendation by @Taifun here:

For me, testing it on companion and going through screens worked with no issues.

Does the crash happen in your sample?
If yes, does it happen when using companion or .apk?
If no, how can I test your app to see what the issue is?


It is 45.5 MB and not 4.5GB…

You should have read what @Taifun already suggested

You do not mention the pixel size of your images thereof, I can only assume that they are 800*1400px if not larger.

Memory consumption for 800*1400px

Density 1 (( 800 * 1400 ) * 32) / 8 = 4.27 MB
Density 2 ( 2 * 2 ) * 4.27 = 17.09 MB
Density 3 ( 3 * 3 ) * 4.27 = 38.45 MB
Density 4 ( 4 * 4 ) * 4.27 = 68.36 MB

Your phone has probably density 4



Like I said, when I delete all the images and fonts, the crash disappears. I’ll have my wife create some placeholder images of approximately the same size, and see if I can reproduce it, then upload the resulting .aia. This clearly has something to do with the way images are being rendered.

The button images are 45x125/250, and 71x125/250. The background image is 666 × 1121. I’m pretty sure my screen would be density 4.

My point is: the app ONLY crashes (with loaded images) when I open and close screens. In fact, it only crashes when I open and close all 4 secondary screens. I can open and close three screens all day long, for 30 minutes, execute code, the whole works, with images loaded and not induce a crash. I can open up the app, do nothing up open and close each screen, in any order, and the moment I attempt to open the 4th screen, it crashes. This strongly indicates to me that something associated with opening a screen is not being properly handled by the “close screen” function, and the functional result is a memory leak that triggers a crash.

Also, unless my phone, no matter what I have running, has exactly the same amount of memory available/unavailable, which I think is unlikely, I’m thinking I’m hitting some kind of memory resource limit not related to the actual available system memory.

Digging through Google, I see quite a number of similar situations, where folks with a moderate number of screens, and a moderate number of images, have similar problems. It’s always corrected by a workaround in the form of reducing from 5 to 2 screens, etc. I’ll stake my twenty years worth of software qa and troubleshooting experience that this is a systemic bug that’s only triggered by a combination of several screens and the use of images embedded in buttons, etc.



I’ll bet money that this is the problem…

“To allow multiple running processes, Android sets a hard limit on the heap size alloted for each app. The exact heap size limit varies between devices based on how much RAM the device has available overall. If your app has reached the heap capacity and tries to allocate more memory, the system throws an OutOfMemoryError.”

This article discusses a similar situation and various methods used to reduce memory usage.


I’d like to be able to track, while the app is running, how much memory is being used by the app - specifically, the heap size. Is there an extension that allows me to do this? I’m still trying to figure out exactly what is triggering my app to crash, and convinced that the “close screen” function is not working as intended (the debug output suggests this as well, as there are only two surface destroying events even though I’m cycling through 4 screens; even discounting that the last screen open triggers the crash, I should still see three close screen options beforehand).

Thomass-iMac:appdev tvleavitt$ grep Hesiod out | grep Screen | grep Destroying | grep -v Screen1 
11-01 13:27:13.406  1795  2830 I WindowManager: Destroying surface Surface(name=com.appybuilder.thomleavitt.HesiodWorksandDays/com.appybuilder.thomleavitt.HesiodWorksandDays.ScreenSayings) called by 
11-01 13:27:17.040  1795  3468 I WindowManager: Destroying surface Surface(name=com.appybuilder.thomleavitt.HesiodWorksandDays/com.appybuilder.thomleavitt.HesiodWorksandDays.ScreenShowList) called by 

I’m also trying to determine how AI is sizing my background image, here’s some output from ADB logcat:

MediaUtil: getBitmapOptions: sampleSize = 1 mediaPath = hesiodback.png maxWidth = 720 maxHeight = 840 display width = 1440 display height = 2392

There’s no setting that lets you define the height and width of a background image. My interpretation of the output above is that there’s no point in loading a background image larger than 840x720. Is that correct?


Since I haven’t had any luck actually tracking down the exact cause (still think that “close screen” doesn’t do what it says it should do and results in a memory leak), I bit the bullet and rewrote the app to eliminate two of the four additional screens. I probably should have consolidated them to something other than Screen1, but oh well, maybe I’ll do that later. At least I get to shove my app out the door.


Please prepare an example as small as possible, which demonstrates this issue and add the project (aia file) into this thread together with exact instructions for how to elicit the error, so someone can take a look