I got some Android apps that plays rtmp streams, and they were working fine on background using Air 2.6-2.7 for about a year until now.
So today, I made upgrades using Air 3.3, and the backrgound playback is not working anymore, as soon as the screen shuts off, the audio shuts down in about 1 second.
I am using Windows Flash CS6. Anything changed in that department? I tried googling it, but nothing useful came up.
Same issue here, glad I found this thread. Also using CS6 on windows, also using rtmp (rtmpe actually). If I leave the app and go do other things, audio continues to play, but after about 10 seconds or so, it stops until the app has focus again. Is there a new permission or setting we must set/change?
thanks for reply, and now I am glad to know that I was not doing something wrong to cause this.
you are exactly right, sometimes the audio continues a little while, but eventually stops after some time, and continues to play only after the app gets focus back again.
and I test my old app with Air 2.7 and the old app never stops and loses the audio playing at any time..
Some more info:
- I have the same apps on iOS too, and using AIR3.3 I made updates of those apps. I can confirm that on iOS everything is working great as it is supposed to do, without any of the same issues like Android / Air3.3 / rtmp stream stopping when the app goes to background mode.
hi everyone. bugs should be entered in our external bugbase here: https://bugbase.adobe.com/index.cfm
would you mind to enter a bug there? please vote on the issue if you are experiencing the issue. the more votes, the more traction it receives. anyways, we entered an internal bug(#3226876) that is under investigation. if you let us know the external bug number, we can bug group them so you'll have some insight to the progess.
about he issue: can you point us to a sample app that reproduces the audio problem? i'm sure we have media internally that test the functionaly, but it's always best to test with real world examples. thanks...
Dear sender,
I am out of the office from Friday, 20th of August, until Friday, 3rd of July.
Your email will automatically be forwarded to Matthias Wiggermann (matthias@jumero.de) and Jan Würdemann (jan@jumero.de) - they will be pleased to assist you.
Thank you very much.
Kind regards,
Uli Niggemann
Thank you for opening the bug.
I have voted for it as well.
Unfortunately adobe has closed the bug, saying this is expected behavior on ANDROID devices. I am not sure what this means, since background process functionality had been added to air 3.3 for IOS.
Any suggestions on what to do next will be really appreciated, since the music app I'm developing at the moment had lost a major functionality.
Thanks
ok, I see. This MUST BE A JOKE! The official response from Adobe is:
Jing Chen6:45:56 PM PDT Jul 23, 2012Hello,
After discussion with the developers, we decided that this should be a expected behavior. We want to have consistent behavior across all ICS and pre-ICS devices. The content playback will pause if the app is in background so other application can use the hardware.
If it impact your business and work, feel free to give it a vote, and comment on how it effects.
Thank you,
Jing
Jing Chen2:49:47 AM PDT Jul 23, 2012Hello,
Thank you very much for reporting, this issue is tracking internally, and I'll add notes here as soon as I get any updates.
Thanks,
Jing
was able to speak to someone on the issue... the bigger picture was some devices would lock the audio hardware preventing phone use or the like. to prevent this from happening, a decision was made to release the hardware when going into the background.
there does seem to be a feasible work around that he pointed out here:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fla sh/media/Sound.html
This code plays audio even when the app is in background
channel = new SoundChannel();
soundPlay = new Sound();
urlReq=new URLRequest;
urlReq.url="urlOfStream";
soundPlay.load(urlReq);
channel = soundPlay.play();
Thank you very much for your answer. However, your solution only points the inconsistency of AIR behavior. If a decision was made to disable background audio in ANDROID, how come one method of playing sound in the background works fine, yet another one doesn't? In my app for example I'm using video streamed from YouTube, and the background behavior of the app changes from ANDROID version to a another, and it's also strangely affected by the quality I set to the played video.
It's also weird since the latest AIR version added background music functionality on IOS, yet Adobe didn't inform it's developers of the new decision made regarding ANDROID background behavior.
As a flash developer I am confused, since there is no documentation pointing what to expect from background behavior.
I personally wouldn't complicate the matter with yet another situation (which seems more of a fringe case than anything else). Let's get core, expected functionality working, then worry about other feature requests (I don't even think the browser keeps playing content after you close it BTW)
The problem again is, that I don't have any documentation regarding the background behaviour of different classes. I don't know if stageWebView is supposed to keep running in the background or not, the same about embedding the YouTube player using the actionscript API (like I've said - it has different behaviour on my phone using ANDOID 2.3 and on my tablet using ANDROID 4, and on my phone it's also strangely affected by the video quality).
So, If I don't know what behaviour to expect I can't tell if it's a bug or a request for a new feature...
while waiting for air sdk 3.5, I downgraded air sdk to 3.0 and published some app updates, of course lacking many of the newer features, expecially the cool ANE stuffs.
if you google old air sdks, there is adobe page with downloadable links all the old air sdks all the down to 1.5 .
the link is currently: http://helpx.adobe.com/air/kb/archived-air-sdk-version.html
Dear sender,
I am out of the office from Friday, 31st of August, until Friday, 17th of September.
Your email will automatically be forwarded to Matthias Wiggermann (matthias@jumero.de) and Uli Niggemann (uli@jumero.de) - they will be pleased to assist you.
Thank you very much.
Kind regards,
Jan Würdemann
North America
Europe, Middle East and Africa
Asia Pacific