@Quidn Thanks for this I will look at fixing this at the same time as the crash problem above.
V5.37 - Feedback
- Thread starter MacroDroidDev
- Start date
@Endercraft can you please provide specific details or report a bug. I've done some very quick testing and it looks ok but I guess there is some specific scenario where it can break.
It looks like you are correct, this is using reflection and for some reason I thought this specific functionality no longer worked on modern Android versions. I have just tested on Android 13 and it does in fact appear to be functional. I will change the implementation to use this approach.
MacroDroid certainly never collects or shares any personally identifiable data in any kind of Telemetry/Analytics/Crash reporting so GDPR is not relevant as this only applies to personally identifiable data.
I think it's pretty obvious 99% of people who pirate MacroDroid do so to just to steal the pro version of the app and no other reason.
That's mad, it's not exactly an expensive app.
I am really tight when it comes to paying for apps , but even I gladly stumped up for pro after just a couple of weeks of seeing the benefits of MD.
I think it depends on whether you feel MacroDroid's price is high or low.
I think @MacroDroidDev is making a statement based on statistical data so far.
Jacob L
Moderator (Lawsonator)
I thought it would be good for people to opt out of any telemetry.co wish people wouldn't pirate MacroDroid. It won't be long before I attempt another round of code purchases
Update:
After a bit more playing around I haven't noticed any problems moving the IF clauses around either expanded or collapsed. The only issue I have noticed so far (more a minor irritation than a problem), sometimes when moving an action into an IF clause the action jumps to the top rather than going inside. This doesn't happen every time though and it's very difficult to get it to do it on command so I am assuming there is a certain place within the area inside the clause that isn't quite right. I hope that made sense.
I will try and do a screen record at some point if I can.
After a bit more playing around I haven't noticed any problems moving the IF clauses around either expanded or collapsed. The only issue I have noticed so far (more a minor irritation than a problem), sometimes when moving an action into an IF clause the action jumps to the top rather than going inside. This doesn't happen every time though and it's very difficult to get it to do it on command so I am assuming there is a certain place within the area inside the clause that isn't quite right. I hope that made sense.
I will try and do a screen record at some point if I can.
I'm not sure I understood correctly, but it seems that you're saying a lot of people wants to be avoided from telemetry for their privacy by using a pirated copy.
I don't know that something has been added to the free version in this beta which could cause such misunderstandings in any way, but I'd say one thing is certain. Not many users piracy for that reason and believe me actually majority of users are don't care at all about that.
Especially it's hard to agree that a pirated copy from unknown source could be a privacy-friendly alternative. Please correct me because I don't know if there are some trustful hacktivists doing for privacy.
Some people just don't want to pay even half of current price if something is available for "free". It's not to say like "it's cheaper than a dessert for some and blah blah the whole family for some others", instead, I believe there are some people piracy MacroDroid like a habit just because it's available for "free" in their beloved secret trove. Not depends on how they feel the price.
And I certainly believe both two would be true.
Although it's not related only to this beta, but is it practically possible to using a different package name for beta releases?
Specifically, when something happens in the beta in a certain device, I can't figure out whether it's newly caused by this beta or not. And I always have to take some risk like being temporarily unusable. That's the fate of "beta" but it'd better to be avoided.
I expect that there may conflicts and several unexpected symptoms like high battery draining, laggy response and something other could be occured especially when install both versions in a same profile and enable same macros.
But it would make possible to install two different versions in a same device, so we can just install each ones into different profiles. Perhaps the caveat should be emphasized and still there are possibilities to conflicts for accessibility services or so on, however I guess basic functionalities would be fine.
So unless if there are a bunch of things to be manually changed when every time when switch the package name, I want to ask please consider to use different package name for beta releases.
Even if someone prefers to use beta as main, I think it's worth to do to disable the Play Store version and then restore in the beta version, for safety and more.
Specifically, when something happens in the beta in a certain device, I can't figure out whether it's newly caused by this beta or not. And I always have to take some risk like being temporarily unusable. That's the fate of "beta" but it'd better to be avoided.
I expect that there may conflicts and several unexpected symptoms like high battery draining, laggy response and something other could be occured especially when install both versions in a same profile and enable same macros.
But it would make possible to install two different versions in a same device, so we can just install each ones into different profiles. Perhaps the caveat should be emphasized and still there are possibilities to conflicts for accessibility services or so on, however I guess basic functionalities would be fine.
So unless if there are a bunch of things to be manually changed when every time when switch the package name, I want to ask please consider to use different package name for beta releases.
Even if someone prefers to use beta as main, I think it's worth to do to disable the Play Store version and then restore in the beta version, for safety and more.
Creating a new package is not viable, because the whole firebase backend depends on the package name to function, this is essential for things like signing into the template store and crash logging etc.
I see. I guess that'd not only related to just continuous experience but also will needs a lot of unnecessary works at backend, even just for collecting crash logs at one place in stable.
So I understand that it's definitely not viable to current situation including the number of testers and so on.
I believe it won't be get too serious because you are usually provide a fix within the same day especially for critical issues.
Claytonmazz
New member
I was hoping the new option to capture text overlays would work for Voice Access . If MacroDroid could capture the text from that app as a trigger, it would open up the gates so wide, it's the only thing I miss from iPhone, the voice control integration with shortcuts. Is this something that would ever be possible, or is it not because it runs as an accessibility service (voice access is an accessibility service I mean)?
. If MacroDroid could capture the text from that app as a trigger, it would open up the gates so wide, it's the only thing I miss from iPhone, the voice control integration with shortcuts. Is this something that would ever be possible, or is it not because it runs as an accessibility service (voice access is an accessibility service I mean)?@Claytonmazz
It certainly seems that Voice Access text is unreadable.
Why don't you write in your Feature Request?
It certainly seems that Voice Access text is unreadable.
Why don't you write in your Feature Request?
sampleuserhere
Active member
After applying a custom rom, for some reason read screen content in old action block returns certain predetermined text instead of the current one.
The first one is the result from the old action block while the later is from the new one I created after restoring MD. Both ran via shortcut.
The first one is the result from the old action block while the later is from the new one I created after restoring MD. Both ran via shortcut.
Endercraft
Moderator (& bug finder :D)
Could be custom ROM's fault, or MacroDroid's fault (or both) but without more information it's hard to come to a conclusion.
sampleuserhere
Active member
It seems that I've figured it out the cause. The action block is actually fine, it's just that the input variable has different behaviour when being called as a shortcut.
It seems that when the input variable is left blank, It's set to literal "null" instead of the default value.
I had if condition that watches over the default value inside the action block, so this behaviour messed up the flow.
It seems that when the input variable is left blank, It's set to literal "null" instead of the default value.
I had if condition that watches over the default value inside the action block, so this behaviour messed up the flow.
sampleuserhere
Active member
Found one 2 odd behaviours in 5.37.8.
- If input variable in action block is left blank, It's set to literal "null" when the action block is called as a shortcut.
- If there is a macro and an action block have the same exact name, the shortcut that originally calls the action block will call the macro instead.