This is an automated archive made by the Lemmit Bot.

The original was posted on /r/tasker by /u/Squidward_official on 2024-05-02 02:34:34.

I am ELATED to bring you this barely intelligible “tutorial” or whatchamacallit. But since this is such a niche issue, only relevant to an equally niche community, and I feel the urge to tell someone about this, allow me to provide some context (feel free to skip this. But it would mean a lot to me if you first understand my struggle and how much I worked my butt off for something as insignificant as this OvO):

______________________________

You may have caught me talking about this before but in case you don’t know, let me tell you how much I enjoy customization. Sometimes, I get ideas on how to massively improve things through minimal changes. But these ideas will stick with me and bug me if can’t actually realize them - like an itch that you can’t scratch. For quite some time now, I’ve been craving more customizable touch controls for my Galaxy Buds+, and there are ways to achieve this with relative ease, but afaik you always have to cut some corners. For example, there already is an additional, unused touch control pattern coded into the Galaxy Buds and you can have Tasker react to it, therefore unlocking an infinitely customizable touch control. But it is necessary to read the system logcat and in order to reliably do so on current versions of Android, you either have to root your device or use the Tasker ADB Wifi method, which is suboptimal in many ways (thanks Google…). But I had an epiphany: What if we modify the accompanying Galaxy Buds+ Manager Plugin/ App instead?

That’s what this is about. And the idea is really quite simple I think. Though, since this is so niche, I couldn’t rely on anyone else but me to actually do this. However, I barely know how to program and I don’t really know how to code, let alone modify pre existing apps! But I was determined because the goal just seems so close to reach. So for the past few days, I was like the monkey in the Infinite Monkey Theorem - smashing my keyboard, barely understanding what I am even doing, hoping I I would eventually get something (desperately).

It appears the theorem holds true, because today it actually happened - I effectively rerouted one of the “Tap and Hold” options to Tasker! But I only learned what I necessarily had to. I still don’t know how to code, and it’ll be difficult for me to explain things as I go over them. Which is why this is less of a tutorial and more like a protocol. I will try my best though!

______________________________

GAMEPLAN:

All I need is to modify the Galaxy Buds+ plugin (or whichever pair of Samsung earbuds you have) for the Wearables app so that Tasker can react to it whenever I tap and hold one of the earbuds. For this, I’m going to alter the code responsible for launching Spotify and replace it with a simple android intent, which then triggers an “Intent received” profile linked to whatever task I want. The choice to modify this specific part of the code is arbitrary - I myself simply found this code the easiest to locate - but unless you alter a different part of the code (the one responsible for launching Google Assistant/ Bixby, for example), you will need to have Spotify installed on your phone, even if you don’t plan on using your custom task in conjunction with it. Just keep that in mind.

But modifying the app alone is not enough, as I’ve learned through hands on experience now, because you won’t be able to install the plugin due to a difference in apk signatures between the modded plugin and the unmodded wearables app. So you need to sign a wearables apk with the same signature as your mod, and then install that. BUT, since this isn’t convoluted enough already, Samsung doesn’t allow you to use modified versions of these apps (using one will give you a notice that the device’s firmware is altered and incompatible).

Luckily, other people – those who use the regular versions of these apps on different firmwares – have already provided solutions for this. These solutions need you to apply a quick fix to the wearables app, the desired plugin, but also the S-health app and some Accessory Service app, if you use them. Now, I’ve reached a point where I don’t ask questions anymore, and I’m also like “don’t fix it if it ain’t broke” - I simply installed all four mods of those apps, even though I don’t even use the other two. I’m not sure if this was necessary, and the S-health app doesn’t work for me anymore either, but I honestly don’t mind. Whether you install these last two mods too or don’t is up to you and some experimentation. Although you will at least need to follow the aforementioned solutions for the wearables app and the plugin of choice.

Also, I strongly recommend you set up a WSL on your computer if it runs Windows.

______________________________

REQUIREMENTS:

(I will provide a small list of XDA posts, old Github projects and other Reddit posts that I used to do all this at the end. There you will not only find better explanations of what needs to be done, but also links to most of the required stuff)

  • apk file of the Galaxy Wearables app
  • apk file of the desired Galaxy Buds’ Plugin for the Wearables app
  • (apk file of the S-health app)
  • (apk file for Samsung’s Accessory Services App)
  • A method to decompile, compile and sign apks: I suggest you install APK Easy Tool if you’re on Windows due to simplicity and ease of use.
  • The capability to run shell scripts originally made in Linux (run the command “wsl --install” in a windows terminal and follow instructions to easily and automatically istall a WSL. You can then open a WSL Terminal in any folder by typing “wsl” in the folder’s directory in the file explorer, just like using “cmd”. You might need this to run a patch file too, so make sure you can run “patch” command in WSL. Search for and install “GNU Patch”, so that you can do that.)
  • ADB setup recommended, specifically the platform and build tools

______________________________

PROTOCOL:

We begin by decompiling all the apks with APK Easy Tool. You now have a folder with the contents for each decompiled apk.

Go to each folder, open a WSL Terminal there and run dansimko’s command line. This, as far as I understand it, allows the apps to work properly despite running on a different firmware (or despite being modded themselves and running on the usual stock firmware, in our case).

The other apps already are good-to-go as is, which means it is now time to actually mod the plugin.

Go back to the decompiled plugin’s folder, and start looking for the CoreService.smali file (for me and the latest version of the Buds+ Plugin, the file was located in smali\com\samsung\accessory\hearablemgr\core\service). The Core service is what actually launches Spotify. If you intend on altering a different part of the code, or if you use a different plugin, I cannot guarantee this is what you will be looking for. You can learn how to locate the code of interest by reading u/bsf91 's modding tutorial. Pro tip: Perform the action that you want to have Tasker react to in the future and look at the logcat logs! For example, I used tap and hold to launch Spotify and, through the logcat, I found some bits of code, strings, logs and other stuff related to the launching of Spotify that I could search for in the code. I recommend you use this Tasker Task to quickly grab the logcat.

Once you’ve found the right .smali file and you’ve located the relevant code, you can go ahead and replace the old code with a simple android intent. You should probably study the code and the language first tho, at least for a bit so that you roughly know what you actually need to delete and what is essential to keep. I see no way around doing some studying here, but it probably won’t take long. If you know someone proficient in smali that can guide you, great! If you don’t, like me, you might want to consider using ChatGPT for assistance. I don’t feel particularly comfortable using AI, nor do I want to wholeheartedly recommend it to other people, but it admittedly is a very powerful companion in these regards - you can literally just dump code or logs or error messages and ask “what is this, what does this mean, what does this do, what should I do now”. You couldn’t do that with your developer friends without it being awkward or you feeling feeling bad or annoying.

Just make sure whatever the code was originally designed to do, doesn’t happen anymore. In my case, I simply removed the lines of code which used to send the intents that launched spotify. The relevant code here starts by defining a new intent-instance in a local registry. This is how you can identify it (or compare it to whatever you found in your logcat, if you want to modify something else other than the Spotify-part of the code):

new-instance v0, Landroid/content/Intent;
const-string v1, "com.spotify.music.features.spoton.ACTION_PLAY_SPOTIFY"
invoke-direct {v0, v1}, Landroid/content/Intent;->