Document how to make media buttons work with TextToSpeech [120951632]

Obsolete

Bug

[AOSP] assigned

Status Update

No update yet.

Description

ry...@ryanheise.com

created issue #1

Dec 13, 2018 03:52PM

There is a whole category of Text-To-Speech reader apps for blind users or news/RSS readers etc. where it is desirable, for accessibility reasons, to allow the user to play and pause playback of TTS via the media button. Unfortunately, the documentation is not clear on how to make this work. Indeed, TTS apps that did this stopped working in Oreo, and there is a workaround confirmed by a Googler in issue

https://issuetracker.google.com/issues/65344811 which is in a not-so-easy-to-find place.

The official documentation of this behaviour appears to be on

https://developer.android.com/guide/topics/media-apps/mediabuttons where it says "If you are running Android 8.0 (API level 26) or later, the system tries to find the last app with a MediaSession that played audio locally. If the session is still active Android sends the event directly to it."

However, this documentation is rather vague. To allow app developers with legitimate use cases to re-enable the media buttons to control audio playback where the system has decided to disable them, the documentation needs to precisely state how the system decides when to deactivate the media buttons. Ideally, the documentation should also mention the workaround confirmed by the Googler in

issue 65344811

, but perhaps in a bit more detail because the Googler's reply leaves many questions unanswered.

- How long after playing silence through the MediaPlayer does its magical effect last for before the media session once again loses its ability to receive media button events?
- If the effect stops after a certain amount of time, is that time measured starting from the start point of that silence or the endpoint of that silence?
- Or is it that you must play the silence simultanously with the call to TextToSpeech.speak()?

The documentation at

https://developer.android.com/guide/topics/media-apps/mediabuttons says "If you are running Android 8.0 (API level 26) or later, the system tries to find the last app with a MediaSession that played audio locally. If the session is still active Android sends the event directly to it."

At the very least, this paragraph should explain more specifically what counts as "audio". Presumably sound played via MediaPlayer and AudioTrack count as audio, and it seems sound played via TextToSpeech does not count as audio. What about SoundPool?

The Googler who replied to

issue 65344811

said that "simple sound effects are ignored when the framework is pick MediaSession for handling media key events." but it is unclear how it determines that something is a sound effect. Is it determined by the duration of the audio being played (e.g. sound effects are short duration) or by the sound API that's used (e.g. sound effects are probably played via the SoundPool API)?

The case has been made above for legitimate uses of media buttons during TTS playback, but the same also applies to sound effects since some of these TTS apps insert sound effects into the stream, e.g. between each article that is read through TTS as signals to the listener, and this may potentially cause the media session to stop listening to media buttons.

Let's improve the documentation so that app developers can implement these use cases correctly.

Thank you.

URL:

https://developer.android.com/guide/topics/media-apps/mediabuttons

Comments

ve...@google.com <ve...@google.com> Dec 14, 2018 05:37AM

Assigned to ve...@google.com.

ve...@google.com <ve...@google.com> #2Dec 14, 2018 09:27AM

We have passed this to the development team and will update this issue with more information as it becomes available.

zo...@gmail.com <zo...@gmail.com> #3Dec 15, 2018 07:31AM

Wtf is this i aint root my phone

ad...@google.com <ad...@google.com> Nov 28, 2019 06:55AM

Reassigned to ad...@google.com.

ad...@google.com <ad...@google.com> #4Jan 28, 2020 11:44AM

Status: Won't Fix (Obsolete)

Thank you for your feedback. We assure you we are doing our best to address the issues reported, however our product team has shifted work to higher priority bugs and may not be able to handle this bug. As for now, we will be closing the bug as won’t fix obsolete.
If you are still facing the issue recently, we request that you log a new bug along with the bug report here

https://goo.gl/TbMiIO

ry...@ryanheise.com <ry...@ryanheise.com> #5Jan 28, 2020 02:52PM

Why are you mischaracterising it as a "bug"? Did you read the description at all? It's a documentation request not a bug, and you should also know that no new documentation or API has come out from Google that would make this request "obsolete", so calling it "obsolete" is either erroneous or obnoxious and insulting to the developers who are still waiting for an answer. It also makes no sense to close the issue and then in the same breathe ask me to re-open it in a new issue. Each time I do that, it dilutes the stars. The original issue had 17 stars. The re-posted issue only collected 4 stars. Do you see how that works? I know you prioritise issues based on the number of stars they collect, so when you ask me to copy this issue into a new issue, you are artificially diluting the stars and artificially lowering its priority so that you don't have to deal with it at the priority it deserves. Though, I'm not sure why Google would want to treat accessibility for blind users as a low priority.

Anyway, I have reposted the issue here:

https://issuetracker.google.com/issues/148400507 as per your request.

xi...@gmail.com <xi...@gmail.com> #6Mar 16, 2020 04:02AM

I have some issue. Playing a silent sound can fix the issue, but I still think it is a workaround. For a code base, it is terrible weird with bad smell.