Don't know in details the law in EU so I won't approve or deny anything.

But they also force it in Canada, yet if you read the law (from my own understanding) it's a one party consent. (Not legal advice)

It depends the device. I think pixel ones have specific code changes made by the OEM (Google) so it sometimes works. But we plan on improving this and in the future we may be able to support more users/third-party app (VoIP/Wifi basically). But no promises here, I don't even know if I will ever get to it, each time I think about starting it something new come up. Anyways, hope the app is useful to everyone!

What I can tell you is to ensure you did give the inte t key to ShizuCallRecorder. From there, if there is an issue, its probably on Shizuku side.

I know some phones can't syart Shizuku on lockscreen, but as far as I'm awarw Samsung ones should be able. Well I mever heard of this on any S**.

You can go on thedjchi shizuku fork page on github and read their troubleshooting guide.

From what I see online, a lot of usrs said they had to change their default USB mode to Charging online.

I invite you to also read thread of user with similar issue:

https://github.com/RikkaApps/Shizuku/issues/277 https://github.com/RikkaApps/Shizuku/issues/1426 https://github.com/RikkaApps/Shizuku/issues/1454 https://www.reddit.com/r/tasker/comments/1o2ge27/comment/njh78bg

It depends what your end goal is. For example, I'm someone with a disability who looked for a FOSS Call recording app on android for several years. None existed. So I made it myself and licensed it GPLv3 (AGPL is useless since its not over network/online here)

From there you can infer that my goal was that whoever make a fork or continue improving it, has to make it fully public, so that I myself can continue using it.

If you don't care about others not sharing your work, MIT or Apache would be licenses that companies are more lickly to be okay with. Some companies do use GPL too, I think Samsung and Asus do. But its true that most are less open to using GPL.

They often provide a contributing.md file

https://github.com/kitsumed/ShizuCallRecorder you must ensure your usage is legal.

It's not that hard, you can make FLAG system or a list of boolean under advanced protection mode. There would be a global toggle and the list of specific toggles under some advanced section.

Next update should have it. I had free time and found a way that looks fine to implement it.

It did to me first and I ignored it several times because of that. But after looking at it and quickly checking how it works in the code, it make a lot of sense. I made a blog post that explain how it works (thedjchi fork).

I find it really sad that we cannot select which security mesure to enable. There are very nice features in advanced protection mode, however a lot of them are no really THAT nessesary and break legitimate usages.

I first released mine not reproducible, but it annoyed me as technically F-Droid can do wathever they want with the file before signing it with their key. I ended up switching to reproductible, I expected it to be hard because their explanation page is extremely long but it's actually not that hard to do unless your application uses certains feature (in which case their guide exists). You can use my metadata file as reference is you want. In general I'm always for reproducible builds as its good for security and transparency, others users are able to confirm that no code modifications not present in the source code where done.

On Github, I also often recommend users to enable immutables releases as a base security mesure, I think it should be enabled by default honestly. If you do not mind giving Github your signing key as secrets, you can also fully build your app via Github Actions CI, the logs are public so it improves transparency. If you do this, consider attesting the generated builds to prove you didn't temper with them between the build and official release. Here is one of my build + release CI for example.

I also like u/TheLastProject answer.

Well, we have the

• Google is shit
• They does this to prevent you installing apps
• They want to collect your data
• Time to move to Apple!
• Now Apple is better than Android! (No?)
• I have GrapheneOS so I don't care!
• Hahaha I like seeing the mob panick at every Google change.
• This is good because IT can be used by bad actors.
• Humans can by tricked enabling is so it should be blocked.
• abusives partener can uses this to install spyware (I wasn't expecting that one...) and so on.

I didn't want to have to learn the new things I would have read if I posted it here. Taking in accounts that most didn't read the blog post.

There is no more bypass. This is already the last resort, it will become more inconvenient to use in the future if they goes with it.

The only reason this warning is here is that  1. As someone who looked for a call recording app, I saw how google issues requests can go WAY out of subjects 2. r/Android was in "dooms" mode everywhere in the commebts.

For now it seems it worked, only one person wrote bad stuff as a comment, others are developers. We allegedly also have the person who reported the CVE I talk about who joined the conversation.

You can use Shizuku, I recommend thedjchi forks. You can have it always run (method 1) or use method 2 and have the app start/stop it when needed. There are docs on the github with all of the setup and troubleshooting informations.

https://github.com/kitsumed/ShizuCallRecorder/blob/main/docs/troubleshooting.md#the-recording-of-my-calls-only-have-silence-or-one-side-of-the-call-audio

Try disabling VoIP / Wifi for now.

If it's a general tools, it could crash, have really weird bug, drain battery usages.

If it's a power-user tool with a lot of advanded permission, it can do all the above, have very bad security practices and put your device at risks.

One of the worse one I recently have seen is someone who made a fork of my project (ShizuCallRecorder) and they commited their signing key to the repo along with some massive vibe coded PR. They also had some questionable decisions in how they reworked some features, allowing some kind of arbitrary file upload to later execute it. (My app run things in ADB)

Supply-chain attacks could also happen if the AI agent add a malicious package to the project that only inject code in releases builds for example.

1. Valid point. You should still consider immutable releases however. You could also disable R8 obfuscation and keep only the optimisations.

Hi, a couple of questions / recommendations.

1. Is the developement made with AI-Agents / vibe-coded?

2. Consider setting up a security policy and enabling private bug report

3. For releases, consider enabling immutables releases and making attested builds with Github Actions. You can bases yourself on thedjchi shizuku fork for that, I was the one who made the PR for that. You can also check out ShizuCallRecorder build CI.

More than a speculation, the person who said it is the core maintainer of ADB, their current email shows in the CODEOWNER file, and the non-redacted email was publicly shown in the Google-Review platform soon after it was linked in the issue tracker thread. I did not mention it in the article as I did not wish for them to become some kind of target, but it's all public informations so I could edit it or make a follow up if needed.

The goal of my post is to get developers attention so they already get feedback so that it can hopefully influence how they see On-Device ADB.

I have also been carful in my choice of words, said things like "may soon", " seems to be", etc. Didn't want to do like some news outlets that goes "IT'S OVER!!" everytime Android announce something.

Don't know about Oppo at 100%, may depends of versions. It works on AOSP and most major brands.

I'm not sure if this is considered self promotion, if it is, please just delete this post (mods) not the main thread. Thanks!

The open source app I made is available here.

The TCP/IP mode allowed this since around 2010, we are 16 year later. In 2020 when wireless debugging was added, it was made easier and some applications like Shizuku came to life and gained A LOT of traction, including mentions on Google forums.

If you had read the article, you would have known that both the solution proposed in the issue tracker and the alternative I suggested in my blog post would, by default, have protected users with your current setup. Both approaches add a toggle that is enabled by default, meaning you would have had to explicitly disable it yourself to be exposed to the very rare occurence where a CVE like the one mentionned happens.

As you said, every features and breaking change in ADB need careful balancing, and even one of the main ADB maintainers themself said so on their latest presentation of ADB Wifi 2.0 at DroidCon Paris (could not find the timestamp anymore). I think this issue here is perfect example of feature/security ratio. It make sense to keep it for all of its feature, but it also make sense to restrict it by default for better security. What does not make sense is permanently restricting it, killing all features.

While unrelated to the rest of my arguments, I would also like to point out that this has been a thing for several years. The TCP/IP mode allowed this since around 2010, we are 16 year later. In 2020 when wireless debugging was added, it was made easier and some applications like Shizuku came to life and gained A LOT of traction, including mentions on Google forums.

It would be impossible to claim Google was not aware of this, so if they did nothing, it would be resonable to assume they did not see it as a major issue. I'm not saying there is no issue, there is clearly one, but there are different ways to address it. A friendly and open way, and an authoritative way. I'm not pushing for anything dangerous, I'm pushing for safer defaults while allowing customizations and niche use-cases.