-
-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tasker plugin #754
Comments
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:
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
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:
Events: Basically something happened. Some states should have events variations because it really helps Task users, while other events can't be states.
|
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. |
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. |
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(?) |
Tasker uses the very old |
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 |
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. |
Okay, I have arrived at an MVP tasker setup: Action: Prepare Playback 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...". |
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. |
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. |
Okay, here's a build with a Tasker action that might work (I really don't know since I can't buy Tasker) @etyarews: |
Ok, it works but it is a pain to know when the service is ready to receive media buttons events. |
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. |
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. |
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. |
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. |
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. |
I've asked the dev about the issue before, he confirmed that Tasker's 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. |
Tell them this: This is really messy. Auxio does have a binder available now in 3.5.0 that follows the legacy My ideal hope is basically that I could do nothing and Tasker would:
From a user's end, then maybe a workflow would be:
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 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. |
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 |
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. |
android.app.ForegroundServiceStartNotAllowedException: Service.startForeground() not allowed due to mAllowStartForeground false: service org.oxycblt.auxio.debug/org.oxycblt.auxio.AuxioService |
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. |
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. |
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 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 |
I see. The most I can say is that you can go recommend a manual build from Auxio's 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. |
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 |
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. |
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. |
I could, possibly, need time to clean it up though first. |
Hey man, any progress on it? I know you're busy with life and things like that, just checking |
#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:
@etyarews? This more or less 100% solves the lifecycle issue and massively reduces complexity on my end. |
I just have two small issues with that:
|
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. |
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 |
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 |
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. |
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. |
Here's a hopefully working tasker build @etyarews: Auxio_Canary.zip |
Officially shipped in 3.5.3. |
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) |
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 |
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)
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) |
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:
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. |
Also, you might want to advertise that Auxio has a Tasker Plug-in |
Self-explanatory, implement a tasker plugin so users don't have to forge intents to start Auxio independently. Docs.
The text was updated successfully, but these errors were encountered: