Remove hardcoded SDK 29 checks in MCAR and DefaultAudioSink

[nift4]

There are some device specific APIs for offload on earlier APIs. Removing these checks allows these device specific APIs to be used by customizing AudioOutputProvider and AudioOffloadSupportProvider, without having to change MCAR or DefaultAudioSink.

For AudioTrackAudioOutputProvider and DefaultAudioOffloadSupportProvider, this change is a no-op. They check for SDK 29 on their own and will just not do anything related to offload on earlier SDKs.

[microkatz]

@nift4

Thanks for submitting this request. Could you elaborate more on your use case? Offload is not a supported feature below API 29 so I'm not sure the issue you are fixing in removing the annotation from APIs that should not be called below that API level. What are the "device specific APIs for offload on earlier APIs" are you trying to take advantage of?

In addition, applications may set their own AudioOffloadSupportProvider so leaving the only check in DefaultAudioOffloadSupportProvider may cause issues if apps don't carry over the API constraint into their customized provider.

[nift4]

What are the "device specific APIs for offload on earlier APIs" are you trying to take advantage of?

Offload was added to AudioTrack java public API in SDK 29. But MediaPlayer had already supported offload for a few years before that, and it's possible to use this offload mode (without also using legacy MediaPlayer, of course) on old devices by importing a few platform header files like AudioTrack.h, AudioSystem.h and a few more from specifically matching QCOM BSP open source releases, or manually coding something generic to access the C++ class (if you're curious: I have something experimental here https://github.com/FoedusProgramme/Gramophone/blob/beta/hificore/src/main/cpp/NativeTrack.cpp). Of course that only gives you that API on the specific OS release the header file is for (others have different offsets and that would cause my app to crash), and it's not a supported public AOSP API, but it's still possible to use offload and I'd like to do that for a specific device I'm working with, because I want to repurpose it as MP3 player.

In addition, applications may set their own AudioOffloadSupportProvider so leaving the only check in DefaultAudioOffloadSupportProvider may cause issues if apps don't carry over the API constraint into their customized provider.

But that's precisely what I want to do: use offload codepath on earlier SDK.

Or do you mean some other app made their own AudioOffloadSupportProvider without having SDK_INT >= 29 check before calling? That check was in the default one from the very first commit it was added (4f0a256), so I would argue it was always expected to have a check inside AudioOffloadSupportProvider.

[nift4]

@microkatz

I have just quickly verified the above, with unmodified media3 main branch, AudioOffloadSupportProvider is already called before SDK 29, so this patch cannot cause an issue there.

You could consider this patch purely clean-up.

  @Override
  public AudioOffloadSupport getAudioOffloadSupport(
      Format format, AudioAttributes audioAttributes) {
    checkNotNull(format);
    checkNotNull(audioAttributes);

    if(SDK_INT < 29)throw new IllegalStateException("sdk 29");