[bug] Sound files in Android's "raw" folder can't be played by ANEs

[myflashlab]

Problem Description

This problem has been with AIR for a long time, I had tried to get more information on this by posting on Adobe's forum before with no feedback. Anyway, this is still happening even in AIR SDK 26.

If an ANE requires Sound file resources, the best place is to put them is the resources raw folder. Unfortunately sound files in that folder won't be played on the native side when AIR packages the .apk. I'm not sure, but it seems like it has something to do with the fact that AIR compresses the resources.

Link to Adobe bug tracker: https://tracker.adobe.com/#/view/AIR-4198415

Steps to Reproduce

• install Firebase Core.
• install Firebase FCM.
• use the Resource Manager Tool to inject your sound files to the raw folder.
  • What is resource manager tool
  • How to use it
• Send an FCM message with a custom notification sound using this article.
• You will see that no sound will be played and you will see the error message in AndroidStudio's logcat window.

Known Workarounds

In some cases, copying the sound files to the File.documentsDirectory instead of the raw folder, can help ANEs play the sound files they need. But this is not ideal. moreover, some ANEs like Firebase FCM ANE is not allowing us to put the fcm notification sound file anywhere else but the raw folder. Because of that, AIR developers using the FCM ANE can not play custom notification sounds on Android.

[PrimaryFeather]

Just to be sure I'm adding the correct labels: this happens on all AIR platforms, right? (I.e. iOS, Android, Desktop).

As for reproducibility: My guess is that if you take the time to create a minimal ANE without dependencies (containing a sound and trying to play it back), and provide Adobe with source + binaries, you'd have higher chances of them looking into it. But it's their call, of course.

[myflashlab]

While I was writing the Steps to Reproduce section, I told to myself "this is too hard to be tested!" So, you're right. Let me build another ANE for this reason, maybe a localNotification ANE to avoid the hard steps of producing the FCM one. Thanks for the suggestion.

[myflashlab]

Oh, and by the way, this happens in Android ONLY on all AIR SDK versions.

[PrimaryFeather]

Thanks a lot for the info — just saw that Android was mentioned in the title, too. Cheers!!

[myflashlab]

Ok, here we go. Here's an easy sample project to reproduce the problem.

Steps to Reproduce

1. Download the demo app here and try to run the ANE on Android according to the instruction.
2. Inject your sound file to the Android's res/raw folder using this software.
3. when scheduling for a LocalNotification to happen, set the sound property like this: setting.sound = "androidSound";

var setting:NotificationAndroidSettings = new NotificationAndroidSettings();
setting.notificationId = 3;
setting.payload = "payload data";
setting.title = "the title";
setting.message = "the message";
setting.time = new Date().getTime() + 5000; // means 5 seconds from now
//setting.sound = file.nativePath; // to play a sound from File.documentsDirectory
setting.sound = "androidSound"; // to play a sound from res/raw folder. Not including the .mp3 file extension
setting.vibrate = true;

Notification.init();
Notification.adjust(setting);

As soon as the notification happens, no sound will be heard and the error shows in AndroidStudio's logcat.

[myflashlab]

This also happens with Video files! Video files packaged inside the apk will be compressed and can't be played in our Augmented Reality ANE. I guess if Adobe is fixing the compression problem for sound files, they should also do the same fix for the video files.

[FabioNani]

Sound problem has solved in Air 29.0 ?

[ghost]

@myflashlab Hi - are you able to confirm that this is sorted now using the configuration settings we've put into the ADT config file? e.g. UncompressedExtensions setting and the change to ensure files in res/raw aren't compressed?

If it's sorted now, please could you close the issue! Thanks

[myflashlab]

yes, it is fixed now. I confirm :) I didn't know this issue was open.