Make bevy_audio optional for android_shared_stdcxx

[Shatur]

Objective

• It's a bit unexpected to require bevy_audio even when it's not used with default_platform, which enables android_shared_stdcxx.

Solution

• Treat this feature similar to std. It just enables android_shared_stdcxx on cpal inside bevy_audio.

[mockersf]

I don't remember the impact at the moment, but a shared stdcxx was needed for some things on android and we were relying on cpal to do it for us

[beicause]

I think this makes sense. I can build for Android successfully when using other audio crate without relying on bevy audio and shared stdcxx.

And after #20323, bevy audio no longer needs it anyway.

[mockersf]

I can build for Android successfully when using other audio crate without relying on bevy audio and shared stdcxx.

As it's a shared library, I think testing needs to be actually playing sound on Android, not just building

And after #20323, bevy audio no longer needs it anyway.

Nice!

[Shatur]

As it's a shared library, I think testing needs to be actually playing sound on Android, not just building

But the whole point was to build for Android without requiring audio. And if it's enabled - enable android_shared_stdcxx on cpal.

[mockersf]

Yup, that was a response to the other comment.

#20323 would do this and more, and merging this first would conflict, so I would prefer to wait for it

[Shatur]

Ah, got it!

Makes sense, but do you think #20323 could go into 0.18?

[mockersf]

do you think #20323 could go into 0.18?

Not likely, #20323 is not ready and waiting for other updates

[NiklasEi]

Not likely, #20323 is not ready and waiting for other updates

In that case can we merge this PR for 0.18?
If we want to encourage people to use the new feature collections and at the same time try out the potential bevy_audio v2 with bevy_seedling, this is a paper-cut. Imo it's just wrong that not adding the audio feature collection is not enough to replace bevy_audio.

[Shatur]

And it's a single character, pretty sure it will be easy to resolve conflicts for #20323 🙂

[mockersf]

In that case can we merge this PR for 0.18?

It is technically a breaking change... but it's probably OK