Obviously the same problem as Kodular.
Did you also check this with the TaifunPlayer?
Just tried and neither does Taifun's player work but this one at least tells me that it can't load audio file..
Thanks for the AAB reports. I've put it on my calendar to look at it this afternoon. If I had to guess, my first thought is that the assets are ending up in a different location when the APK is reconstructed from the AAB than where App Inventor puts them by default in the APK structure.
5 Likes
As I said earlier, there is the same problem with Kodular.
But why does the ExoPlayer work there (if the assets are in a different location)?
@Diego from Kodular implemented the AAB support as a GSOC project last summer. Kodular has had it merged into their system for a longer period of time. As for ExoPlayer, I'm not particular familiar with how it is implemented so I can't really answer that.
3 Likes
If it helps, the extracted apk was decompiled with apktool, edited apktool.yml file and added - mp3 to it, compiled..
Afterwards it worked
P.S. that line exist in apktool.yml file if APK is decompiled..
1 Like
@Boban I think I have a lead on how to fix the asset issue. I'm not sure that I will have it done tonight but I do think I'm close to getting it working.
@Anke I will take up your private file issue next, but if I understand what is happening correctly you may need to change the Scope property from App to either Legacy or Private.
2 Likes
I did test them with extensions (see the PR description here), but that was over a year ago now 
I could have introduced a problem later during my internship, or something could have changed in the mean time.
Either way, I hope the core team can get it figured out. Sadly I don't have time to work on this myself right now, otherwise I'd be jumping to it Making the helper blocks work for extension developers was one of my core concerns throughout the design process. So I really hope that you guys will be able to use them! If not in this release, then hopefully in a future one.
I think they work when you use one of the built-in helper block types defined in the com.google.appinventor.components.common package, but not if you declare your own type in the extension. The way the code is written in the ComponentProcessor, it assumes that the helper type is available in the classpath, which won't be true if the target helper class is being compiled at the same time as the extension.
As a workaround, one could probably compile a separate JAR to define the helper class, and then include that JAR as a dependency of the extension (making it available for the ComponentProcessor).
1 Like
Huh that's so weird! I thought the special directory placement that is required got around that, but I guess not 
Thanks, that helped resolve some of the issues. I think that there may be a bug in how the build system packages subdirectories and so that is preventing the helpers from being bundled in correctly. I should be able to narrow it down from here.
1 Like
A potential fix for the AAB packaging breaking media-related components is pending here:
2 Likes
Ok, thanks:
HelloPurrAssets2.aia (186.8 KB)
But with the APK I get these assets (again: images, webkit):
although these are not present in the assets:
I have tried to put this directory in different places.
This is normal, unless you manually remove them in code.
Why and why does this only happen with the APK?
And why doesn't that happen with the TaifunFile extension?
And to what extent should that be "normal"?
I think the answer is in the link you provided.
My guess is that system relies on this assets to be present in all .apk files. But instead of building them in (which would increase size of all .apk files), Android emulates them via asset API.
I think @Taifun can tell you if its extension makes these system folders invisible.
If these folders are physically in assets, I also think the file component is behaving correctly. Whether we want these folders to be visible or not is another question.