airsdk
Android Crash : Out of Memory Error with SDK 51.2.x.x when lunching application.
Good morning,
In devices with low memory available (it would depend of the size of the app), it crashses with this error
CatLog: No pending exception expected: java.lang.OutOfMemoryError: Failed to allocate a <US_SOCIAL_SECURITY_NUMBER> byte allocation with 3665151 free bytes and 124MB until OOM, target footprint 7330303, growth limit <US_SOCIAL_SECURITY_NUMBER>
SDK: AIR SDK 51.2.2.2 OS: : Android, I couldnt reproduce it myself, but got several cases in Android Vitals for 3 different applications.
I reported this behaviour in another post and according to the log @ajwfrost concluded that handling big files could be the cause, so a fix was added to SDK 51.2.2.2, but unfortunately the high crash rate persisted with that udpate.
So we checked the size of the files our app was handing, each app handles only 3 files, one for app settings (1KB), one for log purpouses (130KB max), and the other file to save the progress of the player. (4 MB max).
After checking the catlog of the 3 apps we get this:
App #1 thread.cc:2097] Throwing new exception 'Attempt to get length of null array' with unexpected pending exception: java.lang.OutOfMemoryError: Failed to allocate a 98842408 byte allocation with 2134023 free bytes and 93MB until OOM, max allowed footprint 4268047, growth limit <US_SOCIAL_SECURITY_NUMBER>
The kley part herer is : 93 MB until OOM SWF Size for APP # 1 : 96 MB:
App #2 Throwing new exception 'Attempt to get length of null array' with unexpected pending exception: java.lang.OutOfMemoryError: Failed to allocate a 80603280 byte allocation with 2306406 free bytes and 61MB until OOM, target footprint 4612814, growth limit 67108864
The kley part herer is : 61 MB until OOM SWF Size for APP # 2 : 78 MB.
App #3 No pending exception expected: java.lang.OutOfMemoryError: Failed to allocate a <US_SOCIAL_SECURITY_NUMBER> byte allocation with 3665151 free bytes and 124MB until OOM, target footprint 7330303, growth limit <US_SOCIAL_SECURITY_NUMBER>
The kley part herer is : 124 MB until OOM SWF Size for APP # 2 : 165 MB.
And checking the reviews in play consoles with that particular app version, users stated that after lunching appliaction it crashes before they could see anything. In all the 3 apps, we only open the configuration file when starting (1 KB), and only handles the log and progress files, after the player chooses an option on the main screen, which shoul be already visible by that time.
So we wonder if there is a possibility that the error is happening when AIR runtime is trying to open the SWF and memory avalilable of the device is less than the required.
@ajwfrost has the last word, as always, we are just trying to give a possible theory.
Another important fact is that with version 51.1.x.x the crash isnt been reported in Android Vitals. It started with 51.2.x.x. This fact make us wonder if maybe a memory validation was removed or changed in version 51.2.x.x that could be causing this crash?
Known Workarounds Rollback to SDK 51.1.3.12
Thanks in advance. We really appreciate all the effort of @ajwfrost and @marchbold giving us a great tech support. Aldo
Hi @jigtrap
Part of me is thinking that if we're not able to allocate sufficient memory to load in the SWF file, then there's not much we can do .. but that doesn't really explain the fact that it changed in behaviour between 51.1 and 51.2.
Are you able to reproduce this yourself? My thinking is that we could try to take stepwise changes between the branches to see if there's anything in particular that then suddenly introduces this problem. I know we switched the mechanism for file loading to use Java/JNI in 50.2.2.3 (see https://airsdk.harman.com/release_notes?q=github-2533) but the code there should have been fairly stable between those 51.1-51.2 versions.. we can review this again though.
thanks
Hi @ajwfrost thanks for your answer,
Part of me is thinking that if we're not able to allocate sufficient memory to load in the SWF file, then there's not much we can do ..
I understand, it's clear that the game won't be loaded if the device doesnt' have the required memory, but... would it be possible to validate the amount of available memory and check against the size of the swf, and if it's not enough we abort the launching of the app in a controlled way, so we don't get the Android crash?
If it's not possible to do this, and in the meantime, and while you analyze possible cause of the issue, could you please build an update of the SDK 51.1.3.12, so we comply with the policy API Level 35 (16Kb memory page support)? Would be more than appreciated.
but that doesn't really explain the fact that it changed in behaviour between 51.1 and 51.2. Are you able to reproduce this yourself?
No, unfortunately we can't reproduce the problema so far, but we will keep trying.
My thinking is that we could try to take stepwise changes between the branches to see if there's anything in particular that then suddenly introduces this problem. I know we switched the mechanism for file loading to use Java/JNI in 50.2.2.3 (see https://airsdk.harman.com/release_notes?q=github-2533) but the code there should have been fairly stable between those 51.1-51.2 versions.. we can review this again though.
Yes, doesn't make sense since next versions after 50.2.2.3 have been fairly stable as you say, so that change doesn't seem to be the cause.
Thanks in advance Aldo
Hi @ajwfrost :
Finally we could reproduce the issue in two Android devices (tables):
-
Alcatel
Model: 8067 RAM 1GB Android: 8.1.0 -
Altron Model: 0B-728 RAM 1GB Android: 8.1.0
AIR SDK: 51.2.2.2 32 bits armv7
I include here the two full catlog files.
Alcatel_8067.txt Altron_0B-728.txt
I hope this can be helpful to find out what could be happening.
If you need aditional information or need to perform special/additional tests on the two devices, just please let me know.
Thanks in advance. Aldo
@ajwfrost , I tried the SDK 51.1.3.12 in the two test devices and the game opened without crashing.
Same code, no changes.
Here are the two full logcat files:
Alcatel_8067_SDK_51_1_3_12.txt Altron_0B-728_SDK_51_1_3_12.txt
I hope you can figure out what's happening.
Thanks in advance Aldo
@jigtrap great that you can reproduce this! The interesting thing I think is how come it's working with 51.1.3.12 so if I send you a runtime based on that, which logs out the JNI array creation etc, we can try to work out the changes. FYI I'm off today so it will probably be tomorrow when I can send you a test build.. thanks
@jigtrap great that you can reproduce this! The interesting thing I think is how come it's working with 51.1.3.12 so if I send you a runtime based on that, which logs out the JNI array creation etc, we can try to work out the changes. FYI I'm off today so it will probably be tomorrow when I can send you a test build.. thanks
@ajwfrost I'll l be more than happy to help. Please, just let me know whenever the runtime it's ready. Thanks
Hi @jigtrap - sorry for the delay, we had been looking internally at the launch process and how the initial SWF file is being opened. It really should be loaded in 4k chunks so I'm not sure how we're ending up with that request for a large byte array..
We've just put some logcat debugging into the 51.2 runtime so would you be able to get the latest AIR SDK, and then from the below zip, extract 'Runtime.apk' into runtimes/air/android/device/ and 'runtimeClasses.jar' into lib/android/lib/
If you then build it for armv7, and run it on your device, it should output logcat traces with the "AdobeAIR" tag, and it should also crash itself if there's a failure to allocate the byte array - in which case, please share the logcat output with the call stack trace and we can find out what's calling through to this method.
thanks
Hi @ajwfrost , here's the logcat:
2025-08-21 09:49:22.625 7635-7635 AdobeAIR pid-7635 I No support for camera on this app 2025-08-21 09:49:24.763 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, size of data = 4096 2025-08-21 09:49:24.763 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, got array 0x439 2025-08-21 09:49:24.763 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, read 4080 bytes 2025-08-21 09:49:24.995 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, size of data = 4096 2025-08-21 09:49:24.995 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, got array 0x455 2025-08-21 09:49:24.998 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, read 792 bytes 2025-08-21 09:49:43.840 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, size of data = 173611158 2025-08-21 09:49:44.115 7635-7662 AdobeAIR pid-7635 I Android file descriptor - read, got array 0x0 --------- beginning of crash 2025-08-21 09:49:44.115 7635-7662 AdobeAIR pid-7635 E Failed to allocate array -> forcing a crash so we can check the call stack
Please let me know if you need another test.
Aldo
Just one info: the available memory on the device was 263 when lunching the app.
"Libre" means "Free".
@jigtrap that's interesting, I was expecting some other lines ahead of those ones!
But in terms of the crash, do you get a call stack a little later in the logcat file? That's what we really need, this function is called from so many possible places within the code that we need to know how it's being called. Given you didn't see any output saying "Platform file stream", it implies it's running in a different way to how it does on a device here..
Alternatively - if there's no crash details, I'm wondering if I could get your APK file and we can run it here, potentially injecting a different libCore.so file to add further debugging.
thanks
Hi @ajwfrost , sorry, I thought I should only send the filltered lines ('AdobeAir'), here's the full logcat file :
https://darkdome.com/test/logcat_hidden_memories_32.txt
And here's the 32 apk file:
http://www.darkdome.com/test/hidden_memories_32.apk
If you need something else, please just let me know.
Thanks in advance Aldo
Thanks, that call stack shows that the file read command is coming in from an ActionScript method.. and the FileStream read command looks a little odd to me, it has an internal buffer that it uses for reading into - unless the read is for a larger size than the buffer, at which point it just reads it all. But the function that calls this is designed to cope with partial reading i.e. avoiding this exact issue by doing smaller chunked reads and building up the final data. (Which is what we'd tried to do in that earlier fix - I suspect actually the issue with that fix was with us not clearing the JNI exception from when we failed to create the array..)
Anyway, attached is an updated version of the Runtime.apk file to go into the SDK under runtimes/air/android/device, this should output the path of the file being opened along with the progress from within the FileStream glue code. And we changed it so it no longer tries to do the read of the whole file, so this might even work! If it still crashes, the whole logcat file would be useful, but if not, just the filtered output like you provide inline would be great.
thanks
Hi @ajwfrost , It didn't crashed (but I think the file couldn't be read)... , so the filtered logcat is here:
https://darkdome.com/test/hidden_memories_logcat_23_08.txt
The logcat stopped logging with an error: "read: unexpected EOF!". Don't know if this is because of a log number lines limit, I couldn't get all the filtered lines anyway.
I copied the first pirt and the last part.
Please tell me if this helps.
Thanks.
That looks good .. yes a lot of logging because reading the SWF 4k at a time takes a lot of calls! It would be really good for your start-up time if you broke down the SWF into smaller ones...
But the end of it you can see it's succeeded:
2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, size of data = 4096
2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, got array 0x675
2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, read 3414 bytes
2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, size of data = 4096
2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, got array 0x679
2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, read 0 bytes
If you divide the SWF file size into 4096 chunks, the final read is only 3414 bytes which is what's shown here.
The curious thing is why this is coming in from an AS3 call though, I might look at some extra debugging to find out what's going on. The root SWF should be loaded via a different call I thought...
thanks
That looks good .. yes a lot of logging because reading the SWF 4k at a time takes a lot of calls! It would be really good for your start-up time if you broke down the SWF into smaller ones...
Thanks for the advice, we will have that in mind.
But the end of it you can see it's succeeded:
2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, size of data = 4096 2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, got array 0x675 2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, read 3414 bytes 2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, size of data = 4096 2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, got array 0x679 2025-08-23 00:05:40.917 14627-14654 AdobeAIR air.com.darkdome.hidden.memories I Android file descriptor - read, read 0 bytesIf you divide the SWF file size into 4096 chunks, the final read is only 3414 bytes which is what's shown here.
Yes, that worked.
The curious thing is why this is coming in from an AS3 call though, I might look at some extra debugging to find out what's going on. The root SWF should be loaded via a different call I thought...
I have double check and the read of the file : /data/user/0/air.com.darkdome.hidden.memories/cache/app/599f9480-ed19-429a-8dfb-9ba8183ad0f0/assets/hidden_memories.swf is taking place before the main class instance is created, so at least the action script of the game itself isn't reading the root swf.
Besides, today I have compiled with the SDK 51.2.3.3 (official) and the app crashes, in the logcat the memory error comes before the main class is created, because we have put a log (trace) that doesn't appear in the logcat .
I have also compiled with SDK 51,2,3,3 ( extra logcat debugging into runtime), and the app opens normally.
So, I am not sure if the the files I replaced into the 51.2.3.3 SDK version had some kind of fix, because with the file replacements you asked me to do, the app opens without crashing. Should I wait for an official update?. Not sure what's the next step, I really appreciate if you could tell me.
Thanks in advance Aldo
Hi
Yes - I would like to see exactly how come that sequence is happening so have just downloaded your APK file, we can replace the libCore library in this with a version that includes more tracing from the ActionScript part too, to see why it's using FileStream...
The patch files I sent over have some debugging but also a way to ensure we don't ask for a massive JNI buffer all at once - although there's probably a more efficient way to implement this. So if this is urgent, we could do a different patch version for you which could be applied? or actually - we were about to start a new release during this coming week so should be able to include this buffered mechanism for sure, even if we'd not sorted out the 'why it's asking' part..
thanks
Andrew
Hi @ajwfrost , I understand, according to Google Play Console policies, we must have our app policies compliant before 1 Nov 2025, so I think we have time to wait for a new release.
One important think to have into account is that this is the only app from 9 Apps we have, that have this problem with Crashses related to low memory. The other 8 apps are doing well with Android Vital Crashes.
Thanks in advance. Aldo
@ajwfrost , i did some tests, taking times until the first frame is shown (our logo), in both SDKS, 51.1.3.12 and 51.2.3.3 (With patch), here's the results in the same tablet (1 gb ram)
as we can see the time with 51.2.3.3 (patch), unfortunately, it significantly affects the game's loading time, so I personally think it would be best to see how version 51.1.3.12 handles the initial loading and see if it's possible to replicate it in version 51.2.3.3. Hopefully, it will be possible. Thanks in advance Aldo
Yes - we've just been looking at some of the way this works, and also trying to ensure we don't impact things too much. I think we have an option that would prevent that dramatic increase in the "after first time" figure there... (and per your earlier suggestion - we don't actually have to chunk the whole file...) => we have done an update which will be in our next release, just waiting for a couple more fixes to go in this so will hopefully be out early next week.
thanks