Comments, Code and Qt. Some words about the wonderful world of software engineering

23Sep/125

Windows Phone 7.5: BackgroundAudioPlayer crashes for published apps

I have been developing a podcast client for Windows Phone for the past few months - just for my own pleasure, to learn Windows Phone development and to have a decent podcast client for Windows Phone. Because it is a podcast client, I need the ability to play MP3 files and lucky for me, Window Phone 7.5 provides a mechanism for this called BackgroundAudioPlayer. It's a bit clunky to set up, but in the end quite straightforward thanks to some pretty good instructions. I got all the pieces of the software working together and I was pretty happy of how it all worked out for me in the end. Including the audio player was working fine. Until I submitted the app for publishing to the Windows Phone Marketplace, that is. The certification failed because "starting to play any podcast episode resulted in a crash". I was quite baffled. I had, after all, been using my own podcast client to listen to my own podcasts for quite some time, including playing them of course. And I mean playing a lot, since I had been using the app for quite some time before I did the submission to Marketplace. This was driving me nuts because I just couldn't reproduce the issue (ok, to be frank I had other issues I had to fix too, but the root cause I couldn't reproduce). Thanks to a brave and kind beta-tester I managed to finally get closer to the truth, because he could reproduce the crash on his device and the version that was downloaded from the Marketplace through the beta-program. In the end, the reason is that a version of the application that is downloaded via Marketplace, and that had gone through Microsoft's signing process, does not by default contain the required capability to play audio on the device. When you deploy the app from Visual Studio on your device from your local machine, the application gets by default all security capabilities. BackgroundAudioPlayer requires the following capability to work:
ID_CAP_MEDIALIB
But apps from Windows Phone Marketplace will not have this capability by default, even if you use BackgroundAudioPlayer. If you examine your app in Windows Phone Dev Center you can see that this capability is missing. You also cannot manually add capabilities for your app (they are listed in the app's manifest file, but that file is only for local deployment). Microsoft's signing tool does not recognize that your code requires this capability, although it should do so. Also funny, that, at least I haven't found, there's no mentioning of this capability in the official documentation for BackgroundAudioPlayer at all.

The solution

So if you visit this page because you Googled why your published application crashes when it tries to play audio, but your development version of the application does not, this is the solution for you: put the following line of code anywhere in your code. It doesn't really matter where, but obviously to a place that is probably not accessed too many times as this code really needs to be executed once.
Microsoft.Xna.Framework.Media.MediaLibrary library = new Microsoft.Xna.Framework.Media.MediaLibrary();
When you reference to this XNA framework's MediaLibrary component in your code, Microsoft's signing tool recognizes that it has to add the ID_CAP_MEDIALIB capability for your app. You can verify this by visiting the app's details page in Windows Phone Dev Center. So it's just a workaround for the problem as it so happens that the line above includes the same capability that BackgroundAudioPlayer requires. When I added this line into my code and did a new beta-release of my app, I could suddenly play the downloaded music file in the version that was published through Windows Phone Marketplace (through the beta-program, but still Microsoft's signing process).

Afterthoughts

To me this sounds like a bug on Microsoft's behalf, because of course I am not using XNA nor access the phone's media library in my app. I am just playing MP3s that are downloaded locally to the app's Isolated storage. But the signing process doesn't act properly when I use BackgroundAudioPlayer in this situation by ignoring the capability that it requires. It's also very frustrating to develop the app when I as a developer expects that the local SDK would act similarly compared to the signing process when it's deployed through Marketplace. In this case I had to make a beta-release for myself in order to reproduce, test and verify the issue. There's no way to debug these apps that are downloaded from the Marketplace and each deployment through the Marketplace takes between 5-8 hours. Microsoft is not going to win any developers over with this kind of experience. This is also not the only severe bug that I encountered while developing the app for Windows Phone 7.5. But thanks to an active community over at Stackoverflow, I managed to overcome some of the issues.

Technorati Tags: , , , ,

  • flatplanet

    I have exactly what you wrote! Thank you! I hope that I made my last beta submission (after 10 maybe). I spend 4 days to fix it…

    • Glad I could help 🙂 It’s weird and sad that Microsoft still hasn’t fixed this…

  • Mido

    Thanks a lot!. It helped me :). And till now MS hasn’t fix it!

    • Glad it was useful 🙂 Sad to see this still being an issue from Microsoft side. Shouldn’t be that hard to fix it…

  • Thanks for the article, it helped me a lot! I’m glad I found it before submitting 🙂