Hi all, build 971 is our candidate. We’re going to let this bake over the weekend.
We’re aiming to release this on Monday and then resume daily builds the following Monday so we can get some features in that didn’t quite make it into the public release, like Android remote push notifications 
Please let us know if you see any \ *regression * bugs between this build and 894 (the last public release).
walter [import]uid: 26 topic_id: 33066 reply_id: 333066[/import]
Great news, both the release, and the Android remote Push being “on deck”. I’ll be working this weekend, and be sure to give the more recent changes (that I’m using) a workout. [import]uid: 79933 topic_id: 33066 reply_id: 131328[/import]
And there was much rejoicing!
I installed 971 tonight, and while it’s early, so far so go!
[import]uid: 19626 topic_id: 33066 reply_id: 131331[/import]
Great news, both the release, and the Android remote Push being “on deck”. I’ll be working this weekend, and be sure to give the more recent changes (that I’m using) a workout. [import]uid: 79933 topic_id: 33066 reply_id: 131328[/import]
And there was much rejoicing!
I installed 971 tonight, and while it’s early, so far so go!
[import]uid: 19626 topic_id: 33066 reply_id: 131331[/import]
Oh, so yet another week delay on the Android Push Notifications. This has been the ugliest dev process I’ve been watching for quite some time. Carlos promised it 6 months ago, David 2 months ago, Joshua 2 weeks ago, later changed to early next week, and now it’s yet another delay. We’re still left in the blue as to when it will actually be available in a daily build.
With a game out that is close to impossible to play without this functionality, and 1 million + players, we’re being slammed day out and day in for the lack of Android Push Notifications. Based on your promises we’ve announced the feature several times. Meanwhile the ratings are poor, the user experience is poor, the revenue suffers, the virality suffers.
So… Can someone PLEASE step forward and give us the CORRECT release date for Android Push Notifications (with GCM)?
Thank you. [import]uid: 21746 topic_id: 33066 reply_id: 131410[/import]
Oh, so yet another week delay on the Android Push Notifications. This has been the ugliest dev process I’ve been watching for quite some time. Carlos promised it 6 months ago, David 2 months ago, Joshua 2 weeks ago, later changed to early next week, and now it’s yet another delay. We’re still left in the blue as to when it will actually be available in a daily build.
With a game out that is close to impossible to play without this functionality, and 1 million + players, we’re being slammed day out and day in for the lack of Android Push Notifications. Based on your promises we’ve announced the feature several times. Meanwhile the ratings are poor, the user experience is poor, the revenue suffers, the virality suffers.
So… Can someone PLEASE step forward and give us the CORRECT release date for Android Push Notifications (with GCM)?
Thank you. [import]uid: 21746 topic_id: 33066 reply_id: 131410[/import]
We’ve been seeing an issue where our app crashes when loading a large spritesheet (2048x2048, png with alpha channel) on some android devices when we unload a scene and then load a new scene. Corona reports near 0 cpu and texture memory usage after the first seen is unloaded. The bug seems to go away if we load the second scene directly, suggesting that perhaps somehow the first scene has not been completely cleared.
Not sure if it’s a regression, but definitely seems like it might be a corona bug.
We first experienced this problem in the Android emulator, and we’ve also received a report from a tester that it crashes on their Sony Xperia S.
Here are the details of the error as we’ve been able to reproduce it in the android emulator.
Here is the log during the error: http://pastebin.com/raw.php?i=tvJzZrQE
It strikes me as a bit weird that the log says that the device grows the heap to 20MB for the 14,000,000 byte allocation and that seems to work, but then it crashes anyway.
Emulator details:
gpu enabled: YES
CPU Model: Cortext-a8 / armeabi-v7a
vm.heapSize: 48
hw.ramsize: 512
Android 4.1.2 Increasing the heap size from 48MB (the default) to 100MB seemed to solve the problem, but if I understand correctly, many common android devices have a heap under this size.
This is a relatively newly discovered problem so I don’t have any more details yet, but maybe something here will stand out to you guys. [import]uid: 135827 topic_id: 33066 reply_id: 131538[/import]
We’ve been seeing an issue where our app crashes when loading a large spritesheet (2048x2048, png with alpha channel) on some android devices when we unload a scene and then load a new scene. Corona reports near 0 cpu and texture memory usage after the first seen is unloaded. The bug seems to go away if we load the second scene directly, suggesting that perhaps somehow the first scene has not been completely cleared.
Not sure if it’s a regression, but definitely seems like it might be a corona bug.
We first experienced this problem in the Android emulator, and we’ve also received a report from a tester that it crashes on their Sony Xperia S.
Here are the details of the error as we’ve been able to reproduce it in the android emulator.
Here is the log during the error: http://pastebin.com/raw.php?i=tvJzZrQE
It strikes me as a bit weird that the log says that the device grows the heap to 20MB for the 14,000,000 byte allocation and that seems to work, but then it crashes anyway.
Emulator details:
gpu enabled: YES
CPU Model: Cortext-a8 / armeabi-v7a
vm.heapSize: 48
hw.ramsize: 512
Android 4.1.2 Increasing the heap size from 48MB (the default) to 100MB seemed to solve the problem, but if I understand correctly, many common android devices have a heap under this size.
This is a relatively newly discovered problem so I don’t have any more details yet, but maybe something here will stand out to you guys. [import]uid: 135827 topic_id: 33066 reply_id: 131538[/import]
@haakon, Android is very challenging to develop for (see my blog post from last week). Since giving dates got us into trouble, I’m putting an end to giving out hard dates. We’ll provide guidance, but no more hard dates. And in the case of push, we’re working on it, so we’ll announce when it’s ready.
@george18, sounds like you are running out of memory. If you are using storyboard, it may keep 2 scenes live, e.g. to achieve things like a transition effect. [import]uid: 26 topic_id: 33066 reply_id: 131635[/import]
@walter. I put in some debug code to print out the current memory stats before every image load.
Here’s what I see:
I/Corona ( 607): Current texture memory used: 495616
I/Corona ( 607): Current memory used: 845.5205078125
I/Corona ( 607): loading sprite Intro\_BG
D/dalvikvm( 607): GC\_FOR\_ALLOC freed 22011K, 84% free 6409K/38727K, paused 43ms, total 52ms
I/dalvikvm-heap( 607): Grow heap (frag case) to 18.686MB for 12982848-byte allocation
D/dalvikvm( 607): GC\_FOR\_ALLOC freed 7K, 51% free 19081K/38727K, paused 68ms, total 68ms
D/dalvikvm( 607): GC\_CONCURRENT freed \<1K, 51% free 19081K/38727K, paused 18ms+19ms, total 111ms
D/dalvikvm( 607): GC\_FOR\_ALLOC freed 158K, 51% free 19111K/38727K, paused 45ms, total 46ms
I/dalvikvm-heap( 607): Forcing collection of SoftReferences for 12982848-byte allocation
D/dalvikvm( 607): GC\_BEFORE\_OOM freed 9K, 51% free 19101K/38727K, paused 61ms, total 62ms
E/dalvikvm-heap( 607): Out of memory on a 12982848-byte allocation.
I/dalvikvm( 607): "GLThread 75" prio=5 tid=13 RUNNABLE
I/dalvikvm( 607): | group="main" sCount=0 dsCount=0 obj=0x4104f220 self=0x2a1322c0
I/dalvikvm( 607): | sysTid=623 nice=0 sched=0/0 cgrp=apps handle=705700824
I/dalvikvm( 607): | schedstat=( 9333008975 3369863196 5385 ) utm=846 stm=87 core=0
I/dalvikvm( 607): at com.ansca.corona.NativeToJavaBridge.getBitmapAsset(NativeToJavaBridge.java:~1118)
I/dalvikvm( 607): at Texture memory is in bytes, and memory is in kilobytes. So, in other words, Corona reports that it’s using less than 0.5MB texture memory and under 1MB CPU memory before loading the ~13MB spritesheet and crashing due to a memory error.
There are other scenes in the game that use far more memory than that, and loading those directly seems to work.
Here’s the code I used to get the memory details:
print("Current texture memory used:", system.getInfo("textureMemoryUsed"))
print("Current memory used:",collectgarbage("count") )
print("loading sprite",name) [import]uid: 135827 topic_id: 33066 reply_id: 131637[/import]
Hi, we’ve been several rounds with Coronalabs through Premium support with a similar problem. It has never been properly solved, though they have tried to fix it.
We’re seeing all kinds of freaky behaviour with white rectangles on the screen instead of images to the app crashing. It’s often a java / open gl out of memory error before it happens, but even by enforcing low res sprites and loading only 20-25 % of the device’s reported texture memory, it still happens regularly. Sometimes it happens on app start, sometimes on resume, sometimes when changing scenes.
It looks like this is a bug Coronalabs won’t ever be able to figure out, as we’ve been struggling with this for 6 months, and spent our money on Premium support to get it fixed -> with no luck.
It makes me happy, though, that finally someone else reports having problems with sprites on Android as well. Maybe if several more devs chimed in on this it could get some proper attention over at the Coronalabs lab. [import]uid: 21746 topic_id: 33066 reply_id: 131640[/import]
I dug through the forums and found a few more mentions of this problem.
Joshua Quick said one solution was to set a timer to load sprite sheets instead of loading them realtime because the device might be running out of space on the heap (apparently an issue on older devices), but he also said this issue should be fixed now. http://web-c3.anscamobile.com/forum/2012/08/07/very-weird-texture-memory-problem-android
I tested the above solution by putting the imageload on a ‘tap’ event handler, but it didn’t solve the issue.
In this thread a user says that it works if they pre-load and cache the spritesheet when their app starts, but this solution won’t work for us because we need to conserve memory.
http://developer.coronalabs.com/forum/2012/09/18/out-memory-crash-lower-end-android-devices
[import]uid: 135827 topic_id: 33066 reply_id: 131657[/import]
@haakon, Android is very challenging to develop for (see my blog post from last week). Since giving dates got us into trouble, I’m putting an end to giving out hard dates. We’ll provide guidance, but no more hard dates. And in the case of push, we’re working on it, so we’ll announce when it’s ready.
@george18, sounds like you are running out of memory. If you are using storyboard, it may keep 2 scenes live, e.g. to achieve things like a transition effect. [import]uid: 26 topic_id: 33066 reply_id: 131635[/import]
@walter. I put in some debug code to print out the current memory stats before every image load.
Here’s what I see:
I/Corona ( 607): Current texture memory used: 495616
I/Corona ( 607): Current memory used: 845.5205078125
I/Corona ( 607): loading sprite Intro\_BG
D/dalvikvm( 607): GC\_FOR\_ALLOC freed 22011K, 84% free 6409K/38727K, paused 43ms, total 52ms
I/dalvikvm-heap( 607): Grow heap (frag case) to 18.686MB for 12982848-byte allocation
D/dalvikvm( 607): GC\_FOR\_ALLOC freed 7K, 51% free 19081K/38727K, paused 68ms, total 68ms
D/dalvikvm( 607): GC\_CONCURRENT freed \<1K, 51% free 19081K/38727K, paused 18ms+19ms, total 111ms
D/dalvikvm( 607): GC\_FOR\_ALLOC freed 158K, 51% free 19111K/38727K, paused 45ms, total 46ms
I/dalvikvm-heap( 607): Forcing collection of SoftReferences for 12982848-byte allocation
D/dalvikvm( 607): GC\_BEFORE\_OOM freed 9K, 51% free 19101K/38727K, paused 61ms, total 62ms
E/dalvikvm-heap( 607): Out of memory on a 12982848-byte allocation.
I/dalvikvm( 607): "GLThread 75" prio=5 tid=13 RUNNABLE
I/dalvikvm( 607): | group="main" sCount=0 dsCount=0 obj=0x4104f220 self=0x2a1322c0
I/dalvikvm( 607): | sysTid=623 nice=0 sched=0/0 cgrp=apps handle=705700824
I/dalvikvm( 607): | schedstat=( 9333008975 3369863196 5385 ) utm=846 stm=87 core=0
I/dalvikvm( 607): at com.ansca.corona.NativeToJavaBridge.getBitmapAsset(NativeToJavaBridge.java:~1118)
I/dalvikvm( 607): at Texture memory is in bytes, and memory is in kilobytes. So, in other words, Corona reports that it’s using less than 0.5MB texture memory and under 1MB CPU memory before loading the ~13MB spritesheet and crashing due to a memory error.
There are other scenes in the game that use far more memory than that, and loading those directly seems to work.
Here’s the code I used to get the memory details:
print("Current texture memory used:", system.getInfo("textureMemoryUsed"))
print("Current memory used:",collectgarbage("count") )
print("loading sprite",name) [import]uid: 135827 topic_id: 33066 reply_id: 131637[/import]
Hi, we’ve been several rounds with Coronalabs through Premium support with a similar problem. It has never been properly solved, though they have tried to fix it.
We’re seeing all kinds of freaky behaviour with white rectangles on the screen instead of images to the app crashing. It’s often a java / open gl out of memory error before it happens, but even by enforcing low res sprites and loading only 20-25 % of the device’s reported texture memory, it still happens regularly. Sometimes it happens on app start, sometimes on resume, sometimes when changing scenes.
It looks like this is a bug Coronalabs won’t ever be able to figure out, as we’ve been struggling with this for 6 months, and spent our money on Premium support to get it fixed -> with no luck.
It makes me happy, though, that finally someone else reports having problems with sprites on Android as well. Maybe if several more devs chimed in on this it could get some proper attention over at the Coronalabs lab. [import]uid: 21746 topic_id: 33066 reply_id: 131640[/import]
I dug through the forums and found a few more mentions of this problem.
Joshua Quick said one solution was to set a timer to load sprite sheets instead of loading them realtime because the device might be running out of space on the heap (apparently an issue on older devices), but he also said this issue should be fixed now. http://web-c3.anscamobile.com/forum/2012/08/07/very-weird-texture-memory-problem-android
I tested the above solution by putting the imageload on a ‘tap’ event handler, but it didn’t solve the issue.
In this thread a user says that it works if they pre-load and cache the spritesheet when their app starts, but this solution won’t work for us because we need to conserve memory.
http://developer.coronalabs.com/forum/2012/09/18/out-memory-crash-lower-end-android-devices
[import]uid: 135827 topic_id: 33066 reply_id: 131657[/import]
I’ve just used 971 on macincloud to build an app. No problems on the simulator on macincloud. I’m developing on Windows with 931.
However, on devices the app froze while trying to load *some* images. This happened in 2 scenes. Neither images are particularly big (much bigger ones in other scenes) . In one scene some images were displayed before the freeze. In the other a rectangle displayed before the freeze.
The issue isn’t uppercase/lowercase image names.
Concentrated on this. Changed an image from png to jpg. No difference. For one scene the image has alpha, for the other, no alpha.
Can’t see a pattern here. The one commonality between the scenes is I’m using links (system.openURL). However, neither scene is freezing at the point where I apply the link to an image. These happen later, so unlikely to be the cause.
Happening on ipad3 and iPhone4. [import]uid: 120570 topic_id: 33066 reply_id: 131755[/import]
Mea culpa.
The error was in fact an uppercase/lowercase issue in a foldername, not a filename.
Can’t understand how windows simulator and mac simulator don’t throw errors when there is a case issue in filenames. [import]uid: 120570 topic_id: 33066 reply_id: 131763[/import]
With the new public release (971) I get the following error:
attempt to index global “analytics” (a nil value)
The line is:
analytics.init( id ) I have require "analytics" at the top of the module.
Regards,
Damir. [import]uid: 108334 topic_id: 33066 reply_id: 131827[/import]