[Galaxy S 4 Themes and Apps] esgie:
I have managed to get rid out of the problem on Android 4.1.2 (Note 10.1 - to be exact), which was reading some launcher events, even if talkback was entirely deleted but at least one other accessibility app was enabled, such as "Page 1 of 5" when changing homescreen, when opening folder etc. etc.

I have deleted stock browser entirely - as well as 90% other samsung apps (but have to stay with Touchwiz as Note 10.1 has not very good CM support, ie. not working Allshare Cast, no S Notes etc.) so I cannot say if the same method repeated within other apps will do good or no... but it is working for the launcher and now I can use Floating Notifications without disturbing voice messages AS WELL as I can use TTS in the apps I want.

As usual, there is a huge probability that it will also work for other 4.1.2 Touchwiz ROMs, as the code differences between 4.1.2 roms for various devices seemed to be very similiar in the past (ie. the changes that shall be made to succefully get rid out of Sysscope checks - I have implemented it to my Note 10.1 (almost) without any problems, basing on code changes presented for Note 2 ROM)! So it may be the method for finally getting rid of it on all devices such as S3 or Note 2 running 4.1.2 ROMs - but I cannot check this in practice.

Also, I am no more than weekend "programmer", or is it better to say: Android fascinate and I am not able to spend the time necessary for learning how to write Xposed mods (although they say it is easy...) - hope someone will be able to implement this and share...

The last thing is that the buggy code seems to be very similar in every place it appears in the code, causing unwanted effects; to be exact - the most important part, which needs to be modified, is always the same.

After decompiling SecLauncher2.apk I've made some investigation. I found out that there is no relation to talkback nowhere in the code; every time a code triggering unwanted speech appears, the pattern is the same: app is not checking for the existence of Talkback, but... if the text-to-speech functions are available AT ALL! Probably, it also depends on no. of accessibility apps registered, too, or something else that is checked early and does - or not - a jump in the code, but I didn't waste my time for investigating it, as it is might be not so easy to find (smali is not very elegant...) and - first of all - not essential for dealing out with the bug.

Anyway, the example of buggy code from one of smali's:

.method public open()V
(...)
.line 489
invoke-virtual {p0}, Lcom/android/launcher2/QuickViewMainMenu;->getContext()Landroid/content/Context;
move-result-object v0
check-cast v0, Lcom/android/launcher2/Launcher;
invoke-virtual {v0}, Lcom/android/launcher2/Launcher;->getTextToSpeech()Landroid/speech/tts/TextToSpeech;
move-result-object v0
if-eqz v0, :cond_0
.line 490
invoke-virtual {p0}, Lcom/android/launcher2/QuickViewMainMenu;->getContext()Landroid/content/Context;
move-result-object v0
check-cast v0, Lcom/android/launcher2/Launcher;
invoke-virtual {v0}, Lcom/android/launcher2/Launcher;->setTextToSpeechLanguage()V
.line 491
invoke-virtual {p0}, Lcom/android/launcher2/QuickViewMainMenu;->getContext()Landroid/content/Context;
move-result-object v0
check-cast v0, Lcom/android/launcher2/Launcher;
invoke-virtual {v0}, Lcom/android/launcher2/Launcher;->getTextToSpeech()Landroid/speech/tts/TextToSpeech;
move-result-object v0
invoke-virtual {p0}, Lcom/android/launcher2/QuickViewMainMenu;->getResources()Landroid/content/res/Resources;
move-result-object v1
const v2, 0x7f0e0038
invoke-virtual {v1, v2}, Landroid/content/res/Resources;->getString(I)Ljava/lang/String;
move-result-object v1
const/4 v2, 0x0
invoke-virtual {v0, v1, v3, v2}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
.line 493
:cond_0
return-void
.end method

Easy. Since "line 489" it perform check if the TTS exist then jumps and return void or executes a code responsible for obtaining a string with a quote to say, etc. and finally - to trigger text-to-speech mechanism. Then it finishes.

Well, in practice, in this example we may delete all of the code inside the method from "line 489" to "line 493" (and leave return void at the end) so the launcher will not perform ANY operation related to speaking at all - and that is what we want. BUT - most of the code may differ a little in various places where the bug exist - for example, the code to say "Page x of y" needs to be longer, as it concatenates the string and the number of pages blah blah blah, also the names of methods where the code has been implemented are very different - it might be difficult to create a general rule to delete it completely in a proper way. However, one thing is ALWAYS made in the same way:

invoke-virtual {v0, v1, v3, v2}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I

The code above is essential: it appears after all varying checks/strings operations are finished and it... finally executes the voice!!! Deleting only the line above will result in behavior similar to described above - the difference is that the launcher will: - perform the check for existence of any TTS voice; - then obtain the string to say; - then process the string if needed (ie. adding page number) - etc. etc. - and in final it will... exit without triggering the speech at la grande finale ;)

So, deleting a single invoke instruction results in the same effect, as deleting whole part of code, but "under the hood" it results in the situation (worse than before) in which the launcher performs a few, unnecessary operations related to processing the string which was scheduled to say, without making any use of the results, as the "speak" isn't triggered in the very end.

Please note, that the "unnecessary operations" mentioned above are far from being advanced or complicated - in each case, and they do waste almost zero device resources - so in my opinion, the advantages coming out from unyfing the solution for every bug (look for every appearance of "speak" -> delete the line with the code) are much more important - and hopefully portable! - than finidng a "prefect" solution for each bug separately.

In result, to get rid of this goddamn bug, one shall:

1. find every appearance of android/speech/tts/TextToSpeech;->speak relation in the code

2. remove the line in which it had been found (ie. remove the code for invoking the speak method mentioned above).

And... that's all.

In the summary, I wanted to add that "damaging" the code for android/speech/tts/TextToSpeech;->speak may be a method to deal with all the bugs at once - but also will result in a totally-non-working TTS, so we won't be able to use it when we really want to.

And last but not least, here's effects of running grep -r speak ./SecLauncher2/smali - which shall return all code lines in which the speak trigger appears in the code (please note that there are no other appearances of the word "speak" in whole code other than in "android/speech/tts/TextToSpeech;->speak") - for my decompiled SecLauncher2 from Note 10.1:

./SecLauncher2/smali/com/android/launcher2/MenuAppsGrid$MenuAppsGridFolderMgr.smali: invoke-virtual {v2, v3, v4, v5}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
./SecLauncher2/smali/com/android/launcher2/MenuAppsGrid$MenuAppsGridFolderMgr.smali: invoke-virtual {v4, v5, v7, v6}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
./SecLauncher2/smali/com/android/launcher2/PageIndicator.smali: invoke-virtual {v1, v0, v2, v3}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
./SecLauncher2/smali/com/android/launcher2/QuickViewMainMenu.smali: invoke-virtual {v0, v1, v3, v2}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
./SecLauncher2/smali/com/android/launcher2/QuickViewWorkspace.smali: invoke-virtual {v2, v0, v6, v3}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
./SecLauncher2/smali/com/android/launcher2/QuickViewWorkspace.smali: invoke-virtual {v1, v2, v4, v3}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
./SecLauncher2/smali/com/android/launcher2/Workspace$WorkspaceFolderMgr.smali: invoke-virtual {v2, v3, v4, v5}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I
./SecLauncher2/smali/com/android/launcher2/Workspace$WorkspaceFolderMgr.smali: invoke-virtual {v5, v6, v8, v7}, Landroid/speech/tts/TextToSpeech;->speak(Ljava/lang/String;ILjava/util/HashMap;)I

As you can see, there is not much to change at all, as there are only 8 situations in which the launcher opens its mouth without permission - so 8 lines to delete ;]

Hope it'll help to develop an "universal patch" for this bug, at least for 4.1.2 Samsung devices. I'm not familiar with Xposed programming but I hope some kind of substitution/overloading of the code triggered by android/speech/tts/TextToSpeech;->speak to an "empty" one (ie. one performing no operation at all) without pointing precisely to exact classes or methods which may differ between devices.

Thanks for your attention and sorry for so huge posting.