Debugging app crash?


#21

@Taifun - I haven’t had the time to chase down my wife and get her to create dummy graphics, but once I do, I’ll post an example.


#22

a question @Thomas_Leavitt, since the whole thread is about this app.
Is it made with responsive or fixed

two of your images and their sizes
666 × 1121 px
1508 x 2168 px

these are not the right size if you read Using Images with MIT App Inventor

Synopsis: App Inventor works best if you use images whose size matches the size you want them to appear on your screen. If you import larger images into your app, your app may run out of system memory.

Boban


#23

I’m running my apps on an LG V20 with a native resolution of 2650 x 1440. The apps all use “Fixed” sizing.

Using the 4 bytes per pixel calculation, the size of my SINGLE background image is 3MB (666x1121x4). Which, I will note, is totally appropriate as a background image on a modern smartphone, and not even half the native resolution of the device. Even the larger image, which isn’t normally loaded, is only 12MB. My phone has 4GB of memory. Unless (and the page is really obtuse here on when this applies) the image is being scaled by a factor of 16 (4^2) due to being a high density device? In which case, it would be using 48MB of memory, kind of absurd, but still… the phone has 4GB of RAM, I find it hard to believe that even that would cause a problem.

I really think it has something to do with memory allocation when multiple screens are being opened (and properly closed), and perhaps heap size (as outlined in one of my posts above), because, as I point out above, the exact same images, on a smaller number of screens, don’t create an issue.

This is simply unreasonable behavior that equates to not being able to use even a single semi high resolution image in any apps. I’m not loading a 1000x1000 image 20 or 30 times on a single screen (incredibly stupid), and having it scaled down to 30x30. I’m not even taking a single 3000x3000 image and having AI automatically downscale it.

Seriously, a mid-1990’s era Windows PC with a 17" CRT running at 1280x1024 could display this background image in an application with no problems, using hardware a fraction of the sophistication and power of a modern smartphone.


#24

@Thomas_Leavitt I suggest you make a thread in MIT forum about this, then maybe some of the developers can explain better to you how everything works…

Boban


#25

you are guessing…
as already said, what about providing an example project 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

Taifun


#26

I created a dummy app with dummy graphics (simple gradients) and it doesn’t crash. There’s no “logic” other than opening and closing screens. It seems pretty clear that memory usage is a product not only of the resolution of the graphical elements, but their complexity (not just a simple per pixel allocation regardless of content). Again: this version of the exact same code, with different graphical elements, DOES NOT CRASH (the first two versions of my app didn’t crash, either, and have no recorded crashes in Google Play, despite hundreds of downloads).

I’ve also included an .aia that when built crashes on my LG V20, reliably. I’d upload the .apk, but it is 4.1MB and thus too large (can we at least get that limit upped to 5MB, @Hossein ?). Simply open and close every screen, once, no matter what order, and the app will crash with OOM errors. The only difference is that the graphic images themselves are larger files (but the same dimensions). Again: no “logic” other than opening and closing screens, and whatever elements are incorporated via the UI designer.

This isn’t pressing, per se, as simply reducing the number of screens while using the exact same logic and graphical elements eliminated the problem, but I’m uploading it anyway, as I’d like to see whatever is triggering this identified, and if it’s an architectural issue or a flaw in the way screens are opened and closed, the problem fixed. Its pretty clear that developers doing entirely reasonable things run into this repeatedly, and the solution is always to work around it.

CrashTest.aia (297.8 KB)
Test.aia (2.2 MB)
CrashTest.apk (2.6 MB)


#27

@Thomas_Leavitt You can upload the .apk to your GDrive and the share the link


#28

I’ll do that. Would be easier to add an attachment though. :slight_smile:


#29

Can anyone try this app and see if you can see any difference in the pictures by clicking the left or right button.

Boban


#30

@Boban_Stojmenovic they look the same to me, but idk what I should be looking for. Does your post relate to this topic?


#31

Of course it does, one of them is 50% smaller, guess which one.

Btw. It’s good that you don’t see the difference between them…:grin:

Boban


#32

From the link you provided: “Returning to the Alphabet example above, if you attempt to load the Project into a device with a screen density of 3 (not uncommon) the Project will try to use 9 times as much memory as the original example with density 1, or 2.3 Gigabytes of memory.”

… I presume this means that on a device with a screen density of 4, the scaling factor is 16, and god forbid, there ever be a device with a screen density of 5. Does anyone else see a problem here?

According to Google itself, the scaling ratio between a density 1 (ldpi) and density 4 (xhdpi) is 0.75 vs 2.0 (significantly more reasonable). Google’s model results in 4x the image size on a density 3 device and 7.11x the image size on a density 4 device. Still substantial, but half as much. They base their baseline on mdpi, instead of ldpi, and that makes everything increase by half as much at the same screen density.

https://developer.android.com/training/multiscreen/screendensities.html


#33

Sorry but I do not understand your calculation on this.

Who has ldpi as baseline.

Btw. Try my app which I posted earlier

Boban


#34

Using Google’s math for a density 4,3,1 screen:

200x200 = 40,000
150×150 = 22,500
75x75 = 5,625

Density 3 device needs an image with 4x the pixels of a density 1 device. Not 9x (AI).


#35

My phone refuses to permit this app to be installed. :confused:


#36

Damn, Sorry try this one

Boban


#37

That worked, no idea what the difference was.

Both sets of images look identical, regardless of whether I click right or left. App doesn’t crash, either.

So, basically, AI is down scaling the larger image automatically?

Was my deduction from the ADB logcat above, that the maximum size of a background image is fixed at 840x720, correct? Is this documented anywhere?


#38

@Boban_Stojmenovic what are your changes to @Thomas_Leavitt app?


#39

Not the same app, different aspect of situation, he’s demonstrating that I can’t display a background image at full resolution. I wonder if the Image component, or the webview component, is also limited this way.


#40

@Thomas_Leavitt There are lots of calculations done before applying image to component. Some of which are:

  • determining if you are running in compatibility mode (fixed or responsive)
  • Determining the density of screen
  • Sampling the image to find-out the efficient loading
  • etc

Regardless, per our PM conversations, this won’t be issue in next release.

Also, fyi, your app icon is 512x52. change it to 76x76. 2> Two of your images are high quality and total to ~2MB and are 16M colors. Try using jpg or compressing the images using such tools as tinypng.com