Tasker plugin

[OxygenCobalt]

Self-explanatory, implement a tasker plugin so users don't have to forge intents to start Auxio independently. Docs.

[etyarews]

Well, might as well throw a wish list. And due to ambiguity, I need to explain things as if someone has never used Tasker.

Tasker has, broadly speaking, the concept of:

1. Contexts: Auxio tells Tasker something is happening/has happened. There's two types: States (thing is happening) and Events (Thing happened)
2. Actions: Tasker tells Auxio to do something. Most of the items in my wishlist can be repurposed as shortcuts. Playback ones are what I consider basic Tasker integration, and those should also have equivalent as shortcuts, I will put a bunch of ideas here with customization to ridiculous degrees, but just basic functionality is actually needed.

When you use a Plug-in Context/Action, usually what happens is that the app opens a fullscreen activity containing configs for that Plug-in Context/Action. This means that, for instance, you don't need an action for each playback option, a single playback action could allow the user to select what type of playback they want Auxio to execute.

Actions

• PlayBack Control: This could be a single plug-in action, with a parameter to select the type of Playback the user desires. It would be cool if rather than selecting the type out of a list, there was a way to use a Tasker variable right there, so Auxio would do %Thing, and %Thing could be dynamically changed inside Tasker. This is the basic functionality I mentioned:

• • Play:
• • Pause
• • Stop: as in, it resets the current track progress to zero and stops playback.
• • Toggle: if there's music playing then it pauses, if the music is paused (or stopped) it plays it. It needs to be a different function from Play/Pause. I personally only use Play and Pause separately, but there are uses for toggling.
• • Shuffle library: Just shuffles the entire library and starts playback.
• • Skip/Next

• Get Info: This would be an action for Auxio to retrieve info right now and send back to Tasker in the form of output variables. Some info can be retrieved through the notification and media info, but would be nice if Auxio itself sent the info about basic playback (current music, album, artist, metadata, etc...), the current... way (?) the music was played (is it an album/artist/playlist/genre or is it just random?), what is the folder method used for the library? What is the folder (s) allowed/denied? When was the last time the library was reloaded? Etc...

• Playback Manipulation: More along the lines of Tasker sending a command so that Auxio plays a specific song/artist/genre/playlist. Or it sends a command to add song/artist/genre/playlist to the queue (after the current song or to the bottom of the list). Or it turns shuffling/repeat on

• Load Library: Ok, this sounds weird but could be really cool in some circumstances. Based on what you've mentioned, I'm assuming that Auxio can stay between 5 and 10 seconds in the background (or more) without receiving a command before it crashesstops and the library needs to be reloaded on playback due to the service being killed by android or something. Why would I want this? Well, Auxio takes a while to load the library, if you want Tasker to do a list of actions related to audio playback, why not start the library loading, do a bunch of actions, and then send the playback command? Like, for instance, a user wants Tasker to control Auxio through voice commands, it could be a button on the home screen. Rather than having to listen to the user, and then starting playback which would require some seconds of loading, it could load the library right from the get-go, listen to the user, and then immediately start playback. This would be useful on really large libraries or if the user wants to reload the entire library from scratch for some goddamn reason.

Contexts

States: Something is happening on Auxio and you want Tasker to do something while the thing happens or stops happening. I can see two vaguely useful states:

• Playback: I.e. Music is playing on auxio, could have filter, like to react once a specific music is playing, they type of playback (random/playlist/artist/album/etc...)
• Library Loading: Tasker to react if Auxio is loading. Might be useful or something

Events: Basically something happened. Some states should have events variations because it really helps Task users, while other events can't be states.

• Playback Changed: Rather than react while audio is playing, reacts when something happened, might be starting playback, pausing, stopping, etc..
• Library Loading Changed: Basically reacts when the loading started and/or ended

[OxygenCobalt]

Okay, I'll need some time to process this.

I think all of these are fine minus Load Library. In Auxio all tasker commands would be queued and then executed once loading and state restore completes. I think instead you just execute your first command and then block on the "Library Loading" state and "Playback initialized" state until it's done, if that's possible.

Biggest issues I see is making sure the lifecycle is sensible and marshalling data around. I need to make sure it's usable by Auxio (i.e UID to use) while also being human-readable (include some extra metadata).

What strikes me is that this is very close to the surface provided by the Media3 API. Given my desire to make sure Auxio doesn't do too much, I wonder if this would be better as an external app that exposes Media or Media3 actions in any app as a generic tasker plugin @etyarews. But that's a lot harder to manage. I think I might start at bare minimum basic playback commands through #753 and a basic tasker plugin, then look into further extensions as they become useful.

[OxygenCobalt]

Re-marking as a maybe due to me needing more time to reflect. Don't worry, this isn't an outright rejection. I'm generally erring closer to this being a good idea since tasker is a "standard" automation tool, and it might provide solid infrastructure if Google decides to introduce their own automation tool a la iOS shortcuts.

[etyarews]

Yeah, this is more of a wishlist, a best case scenario for Tasker integration .

A more realistic expectation is just having an action to Play, which would satisfy most of the users. Actually, depending on the implementation, a single Static Shortcut would be more than enough.

Heck, if there's an ADB command to start playback that's more than enough. Pausing can be done through the notification.

I'm not actually sure if Tasker implementation of Media Controls is up to date. It actually works on pretty much everything once the player has started(I'm making Tasker open Auxio, wait a few seconds then start playback, which sucks because it doesn't work on a locked device), any issues it might have are swept under the rug as users don't expect most media apps to work from a cold boot after Android 11(?)

[OxygenCobalt]

I'm not actually sure if Tasker implementation of Media Controls is up to date. It actually works on pretty much everything once the player has started(I'm making Tasker open Auxio, wait a few seconds then start playback, which sucks because it doesn't work on a locked device), any issues it might have are swept under the rug as users don't expect most media apps to work from a cold boot after Android 11(?)

Tasker uses the very old MediaButtonIntent API that has existed since like Android Froyo I think. What Tasker should do is create a MediaController, bind to the app, and make more complicated requests. But given that Tasker has so much technical debt as is from it's UI and general behavior, I really don't want to make a patch for it.

[etyarews]

Eeeh, Tasker is very slowly getting a redesign to M3, and I'm the designer of that project. I've sent a message to the dev regarding the MediaController thing.

[OxygenCobalt]

I've decided that exposing a raw service API would be far easier to mess up than if I define some tasker actions, so I'll do this instead. I just have to work out lifecycle details though such that it's impossible for a tasker user to trigger a foreground crash.

[OxygenCobalt]

Okay, I have arrived at an MVP tasker setup:

Action: Prepare Playback
State: Available -> Whether Auxio's Service is 100% initialized

Implicit assumptions: You will call Prepare Playback, Block Until Available is True, and then immediately send some playback action that will trigger Auxio to foreground. If you don't, then expect Auxio to crash.

You can just use MediaButtons from then on, hopefully.

Since Tasker is for enthusiasts, I think it's fine to not have very many guardrails. I'll make it more robust if one day Google decides "hm... i wanna copy ios shortcuts...".

[OxygenCobalt]

Wait, are you aware of any Tasker actions that take a long time to execute @etyarews? Perhaps I can just collapse it into one action by just looping until it's available.

[etyarews]

Quite a number of actions can take a while to finish, specially if they involve the internet in some capacity.

A somewhat good rule of thumb is that it shouldn't take more than 30s to run an action. But honestly, the initial plan isn't that bad, but yeah, it it would be better to be a single action.

[OxygenCobalt]

Okay, here's a build with a Tasker action that might work (I really don't know since I can't buy Tasker) @etyarews:

Auxio_Tasker.zip

[etyarews]

Ok, it works but it is a pain to know when the service is ready to receive media buttons events.

[etyarews]

Alright, it appears I need to run the plug-in action two times before it allows me to control Auxio with Media Buttons. I tried putting an wait action between the plug-in action and the media button action, but it doesn't appear to have worked as well as I hoped.

The issue is that the plug-in action only makes Auxio ready to receive media buttons, but there's no way of knowing when Auxio is actually ready. It is missing an state or event.

Either you add an event or state when Auxio is ready, or you refactor the action to immediately start playing.

[OxygenCobalt]

Wait, I see. The action only starts and then blocks until the service initializes but not necessarily restores it's state. Let me quickly tweak that @etyarews.

[etyarews]

While I wait for an update, the workaround I've found was to use an action to start the service, add a 4 seconds wait, then start the service again and only then send a media button action.

I've also managed to make it work while the screen is turned off, which is basically my entire goal, one time I had an issue and couldn't start the service, but because I'm trying to do so while the phone is locked this is difficult to reproduce and narrow it down if it was a fluke or not.

[OxygenCobalt]

I've built out a more robust plugin, but I'm running into SEVERE implementation issues since the "If you go background once you can't go foreground again" issue I've talked about earlier actually exists and applies to ONLY services started by Tasker.

I don't know if I can actually implement this now. Each attempt to fix it has caused another problem and is increasingly wrecking my internal service lifecycle. That lifecycle is already buckling under the weight of the clumsy workarounds I've done to cram in music loading. I seriously risk degrading UX to appease tasker's extremely outdated interface, and that's honestly where I start drawing the line at features.

Is it not feasible for the tasker developer to implement things like MediaController @etyarews? This binds the service and allows me to go foreground whenever, and is basically what the rest of the Android OS uses. I can't tell if it will need a foreground activity itself however.

[OxygenCobalt]

I'm going to ice out this issue for now and disable the current tasker code until I can stabilize the service lifecycle with media3's demands.

For now, enjoy this maybe partially working build with slightly more usable half-built actions.
Auxio_Tasker2.zip

[etyarews]

I've asked the dev about the issue before, he confirmed that Tasker's Media Button Action actually uses MediaController if the media player has an active notification. He was, however, unsure about how to send a MediaController intent without the service existing in some form or another.

He also said he needed a sample of... something that I'm frankly unqualified to describe. Something about a sample of what triggers Auxio to play, or a thing to bind the service.

I'm unsure what you meant by "seriously risk degrading UX to appease tasker's extremely outdated interface", as none of what you described appears to be limited by Tasker's interface, and Tasker's plugins also work with Macrodroid and Automate both which have more modern interfaces than Tasker's default one.

[OxygenCobalt]

Something about a sample of what triggers Auxio to play, or a thing to bind the service.

Tell them this:

This is really messy. Auxio does have a binder available now in 3.5.0 that follows the legacy MediaBrowserService but also the modern media3 APIs too. Auxio never plays without user interaction (ideally), at minimum it will load music, restore state, and then idle. What triggers issues is that I briefly stop going foreground between load music and restore state, and the fact that I also stop going foreground when I begin to idle (I can change this but I don't know if it will have second-order impacts). These are extremely difficult to remedy on my end without risking wrecking more "standard" bound usage of the service. Either way, I need to make it such that the service needs to be bound or for the service to be launched by a foreground activity to still be be allowed to go foreground later in these cases.

My ideal hope is basically that I could do nothing and Tasker would:

• Be able to identify my playback service (through the relevant media intents)
• Start and bind to it (Binding most importantly, this makes my life so much easier)
• Expose relevant state and actions

From a user's end, then maybe a workflow would be:

• Start [Auxio] Media Browser Service
• Wait until [Currently Playing Media Item of [Auxio]] != [Null] (i.e Finished loading and restored state, ensuring that your media intents would work)
• Send command [Play] to Auxio

I'm unsure what you meant by "seriously risk degrading UX to appease tasker's extremely outdated interface", as none of what you described appears to be limited by Tasker's interface, and Tasker's plugins also work with Macrodroid and Automate both which have more modern interfaces than Tasker's default one.

My assumption is that Tasker was forging legacy media button intents and throwing them around, which have always been a nightmare to manage personally. Now that I know it is MediaController, I'm more okay with it. I just wished it went further with binding and starting services.

Send me any response if you get one @etyarews. Better, if you could tell me how to establish contact w/the Tasker developer, that would also be nice.

[etyarews]

He's very active on reddit

[etyarews]

Btw, I tested Automate and MacroDroid and neither could kickstart Auxio without using the plug-in. So afaik there's no app that currently implements MediaController in the manner you wished Tasker would. Which makes it hard to explain and understand how much it would improve with binding and starting services.

[etyarews]

Alright just to make it clear, once this happens if I open Auxio it throws an error that it couldn't load the library and I need to manually tap into reload it, which doesn't make much to me because there isn't really any reasonable option other than reload the library, so it feels kinda weird.

[etyarews]

android.app.ForegroundServiceStartNotAllowedException: Service.startForeground() not allowed due to mAllowStartForeground false: service org.oxycblt.auxio.debug/org.oxycblt.auxio.AuxioService
at android.app.ForegroundServiceStartNotAllowedException$1.createFromParcel(ForegroundServiceStartNotAllowedException.java:54)
at android.app.ForegroundServiceStartNotAllowedException$1.createFromParcel(ForegroundServiceStartNotAllowedException.java:50)
at android.os.Parcel.readParcelableInternal(Parcel.java:4816)
at android.os.Parcel.readParcelable(Parcel.java:4778)
at android.os.Parcel.createExceptionOrNull(Parcel.java:3006)
at android.os.Parcel.createException(Parcel.java:2995)
at android.os.Parcel.readException(Parcel.java:2978)
at android.os.Parcel.readException(Parcel.java:2920)
at android.app.IActivityManager$Stub$Proxy.setServiceForeground(IActivityManager.java:6079)
at java.lang.reflect.Method.invoke(Native Method)
at leakcanary.ServiceWatcher$install$4$2.invoke(ServiceWatcher.kt:93)
at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
at $Proxy3.setServiceForeground(Unknown Source)
at android.app.Service.startForeground(Service.java:743)
at org.oxycblt.auxio.AuxioService$updateForeground$2.invoke(AuxioService.kt:102)
at org.oxycblt.auxio.AuxioService$updateForeground$2.invoke(AuxioService.kt:100)
at org.oxycblt.auxio.music.service.IndexerServiceFragment.createNotification(IndexerServiceFragment.kt:93)
at org.oxycblt.auxio.AuxioService.updateForeground(AuxioService.kt:100)
at org.oxycblt.auxio.music.service.IndexerServiceFragment.onIndexingStateChanged(IndexerServiceFragment.kt:115)
at org.oxycblt.auxio.music.MusicRepositoryImpl.emitIndexingProgress(MusicRepository.kt:584)
at org.oxycblt.auxio.music.MusicRepositoryImpl.access$emitIndexingProgress(MusicRepository.kt:224)
at org.oxycblt.auxio.music.MusicRepositoryImpl$emitIndexingProgress$1.invokeSuspend(Unknown Source:15)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)

[OxygenCobalt]

Really weird @etyarews. This was during normal operation, or when the library issues occur?

Also: The kind of problems you're reporting is why I've kind of iced this issue right now. There's a combinatoric (translation: big) amount of edge cases I have to handle and it's why I don't want to ship this when I'm already dealing with Media3's combinatoric edge cases.

[etyarews]

It is related to the library issue I've mentioned. Sometimes it just gets nuked.

I thought it was the Tasker Plugin action not being executed right, but I'm starting to suspect it happens due to some other stuff, and then the action just makes Auxio confused and then it nukes itself.

[etyarews]

Like, being honest, my issue isn't that it nukes itself, the issue is that after it nukes itself I need to open Auxio and manually tap the reload library button.

It would be a non-issue if Auxio could be reloaded in this state with a Shuffle All Songs action.

I do understand why this is all kinda janky as hell and why you maybe don't want to implement it officially, but I wish there was a more of a semi-official way to obtain the debug version with the plug-in action, that way I could suggest that version of Auxio in the Tasker/Automate/MacroDroid Community, they would be more understanding of the janky than the general public.

I'm not sure if you understand how important this feature is for the small niche of people who want to control a music player through those automation apps. The current solution is to have no proper control at all, like Auxio was, or to use an outdated music player, or build your own music player inside Tasker

[OxygenCobalt]

I see.

The most I can say is that you can go recommend a manual build from Auxio's tasker branch @etyarews. That's where all of the functionality is right now. Perhaps other enthusiasts could fiddle with it and try to fix issues. Otherwise it's on ice for now, as I said.

Also: I think I've finally figured out how to correctly set up the service lifecycle to correctly play along with Media3, with the additional bonus that the "downtime" problem that crashes the service prior should hopefully no longer be an issue. Hopefully the third revision of the tasker plugin should work without much fuss.

[etyarews]

Looking forward to the revision, Auxio has become one of my favorite apps for Android, and that was before the work to implement Tasker functionality into the app.

I'm not familiar with GitHub from the dev side, so I got to ask: can't you make a beta release on the Tasker branch? I'm going to probably link the last debug APK you've shared if that's not an issue to you. That way, non-tech folk can have a somewhat working version of Auxio that has the Tasker functionality without having to build it from scratch.

[OxygenCobalt]

I don't have the infrastructure built to publish nightly builds on the Tasker branch just yet, I think I can into some issues. But ideally whenever I make changes the branch should auto-compile.

[etyarews]

Is it not possible to publish one build? Even the last one you've sent me. What I wish is just one easy to find release that isn't a direct link to the download itself.

[OxygenCobalt]

I could, possibly, need time to clean it up though first.

[etyarews]

Hey man, any progress on it? I know you're busy with life and things like that, just checking

[OxygenCobalt]

I have a route to having an actual working lifecycle that complies with media3 absurdity with #775. This will also enable me to finally start launching standalone services, and thus working tasker actions @etyarews

[OxygenCobalt]

#775 isn't desirable, so I am plucking that off. Luckily I have my backup plan for eliminating the state restore downtime problem, it's messy but it'll work.

Are you okay if the Auxio tasker action flat-out:

1. always started active playback
2. always restores the last playback state
3. errors out if there is no saved playback state

@etyarews? This more or less 100% solves the lifecycle issue and massively reduces complexity on my end.

[etyarews]

I just have two small issues with that:

1. While I can't reproduce it, and it stopped happening, I am afraid of what happens when something bugs out and Auxio just destroys the playback state. When that happens, Auxio throws an error that needs the user to manually open it just to touch a button to rescan the library. Auxio nuking the playback state is fine, what I dislike is having to manually open it just to tap a button. Would prefer a notification, or better yet, some banner, as there is no other choice for the user rather than rescan the library anyway. I would rather it just rescan on the background directly without user intervention. This became a rare bug, so I don't know what cause it in the first place
2. Could you make it so that when there's no playback state it just shuffles everything?

[OxygenCobalt]

Sure, I could just shuffle all. It's not very flexible though @etyarews.

I would have to build out a more complicated tasker plug-in, but since demand is limited, and the only thing I get out of a tasker plugin is confirmation that I have a good service lifecycle, that kind of hard-coded behavior is fine.

[etyarews]

You mean shuffle all only when something goes wrong (no playback, or it got nuked) or shuffle all at all times?

[OxygenCobalt]

You mean shuffle all only when something goes wrong (no playback, or it got nuked) or shuffle all at all times?

Shuffle when something went wrong

[etyarews]

That's perfect by me then

[OxygenCobalt]

That's perfect by me then

Ideally if I extended the tasker plugin the "fallback" command could be customized, but for now this works @etyarews

[etyarews]

Yeah, while I'd love to have more options, the reality is that there is no other music player that can start playback from a cold state through an automation app.

This means that even in a limited state, Auxio is already superior to all the others music player in that niche.

[OxygenCobalt]

Alright, I've finally built a limited tasker action that should guarantee not being footgunned by android @etyarews. I'll share a debug build later, busy with other stuff. I think I'll be able to ship it in a patch.

[OxygenCobalt]

Here's a hopefully working tasker build @etyarews: Auxio_Canary.zip

[OxygenCobalt]

Officially shipped in 3.5.3.

[etyarews]

Sorry I didn't reply earlier, my email app just stopped working for some unexplained reason.

Thank you so much for sticking through the end, I've tested it here and there's an issue:

It doesn't create the media notification, and sometimes it starts playing music directly rather than waiting for a media control input (this is fine, but don't know if it was intended)

[etyarews]

Alright, tested a bit and if it doesn't create a média notification it gets killed by Android after a minute or so.

If after it starts and before it gets killed I rerun the Tasker action, THEN it creates a media notification and it works like before. I think I can work around this, but it is a bit weird

[OxygenCobalt]

It doesn't create the media notification, and sometimes it starts playing music directly rather than waiting for a media control input (this is fine, but don't know if it was intended)

This is the whole point @etyarews. The whole action forces a foreground state by guaranteeing playback so it's impossible to footgun yourself. You're generally playing with dangerous stuff running Auxio's service completely detached, and trying to protect against all cases is basically like thinking about a fractal. It's pretty much always going to be inadequate because foreground services are inadequate (unless you're a streaming app, in which they are A-OK)

It doesn't create the media notification

I don't know how this happens. It was creating notifications pretty clearly from my testing. I'm willing to chalk this up to ROMs differing in their treatment of services (Seriously, this is such a pain)

[etyarews]

It's cause the previous debug build I was using required a media button event to start playback. I wasn't sure if this was intentional or not, heck, it might be something you changed between debug builds and I've never noticed because I never needed to redo my task.

About the media notification, I don't think it has to do with my ROM as I use LineageOS, which is fairly closed to Stock Android. That said:

1. I think this was happening because I didn't disable battery optimizations on the main Auxio app. I disabled it and it looks like it creates notification now. You might want to put an warning in the Tasker Plug-in Action, or create a notification, or something somewhere, just to explain things to the user.
2. Even if it wasn't the battery optimization, a workaround was to trigger the plug-in action again and it would create the notification.

So yeah, this is pretty much complete, thanks again. I started supporting Auxio to get this particular feature implemented, so I will have to stop supporting eventually, but will throw at the very least one more month.

If you don't have anything else you deem important to you (not Auxio), I will prioritize getting Auxio on the PlayStore, that way you might be able to monetize the app directly as a in-app donation or whatever else you'd like, cause paying through the PlayStore is easier than dealing with GitHub.

[etyarews]

Also, you might want to advertise that Auxio has a Tasker Plug-in