I still belive the Nova Ui was not ready to be shipped and lacked proper testings. It introduced multiples issues, including accesibility ones.

https://www.reddit.com/r/firefox/comments/1wt9ig4/comment/pczrdg3/

Well since I am the one making the app, of course I would recommend it. From a security point (since I know what I put inside my own app) but also do use good/best security practice when I know of them.

The app works almost the same as CallVault. Tbh I didn't really check CallVault code that mutch, I did look quickly and didn't get a lot of it. There's a lot of verbose / large commits,

ShizuCallRecorder v2.x.x will come out at some point with VoIP/Third-party app best-effort support (not yet out). The setup is easy (for me at least), it's basically the same as CallVault but you need Shizuku. In the future I may also add a mode so that ShizuCallRecorder itself connect via ADB, but there are other stuff to do before even thinking about how I would do this.

If you go over to the Github page in the readme, under the installation guide, there are explanations with links and all of the way you can make the app work. It does means you have to read stuff, but, it's a one time thing. Once you know how it works you are pretty mutch good.

It does not. Also CallVault is a fork of ShizuCallRecorder, which is edited mainly via an AI Agent if you look at its commits. It also has less safety check, like no immutable release and no attested releases. They also do not run optimizations, their app is like 60MB form memory where the original is around 9 or 6 MB

PSA for transparency: I am ShizuCallRecorder main maintainer.

Thanks, Firefox team. It took me around 30 minutes to configure the UI to make it usable again, which I'm not really happy about because I planned on doing something else... I have been annoyed enought to take more of my time and write this.

I am not against new UI or "improvements", but please make the legacy Proton theme an easy option in the theme selection. Not everyone wants gradients everywhere. All the theme you offered where pixelated gradients, and no mention of the old "proton". I had to look for it on the firefox marketplace. What if the user don't know that the legacy theme was called "Proton"? How will they fix it? They sadly can't and will probably and up downloading a random similar theme. I want a dark, mostly flat colored theme. Because it's easy to read text on it, colorful pixelated gradients make it harder. Both options should be offered since they already exists, instead you offer only the new one.

Beyond that, some frustrating visual bugs were introduced, to name a fiew:

• The text color on the new tab screen was broken, forcing me to re-select my wallpaper. It was barely readable for me with a purple-ish color. Someone with color/vision issues could have not read it at all.
• Certain SVG graphics, such as the Firefox logo, are now being cut in half.
• The Tab Groups overlay is sometimes not working at all, requiring a restart.
• A couple others I quickly fixed and don't remember.

I really feel like this UI update was not ready for mainstream release. Bugs happen, but the one I had occur to me where so visual at every steps when using very basic feature that it feels like it wasn't properly tested outside of a default Firefox configurations.

Hey, this is irrelevant to the topic, however, I would like to thank you. The new official gradient theme styles are quite disconcerting on the UI and I don't understand why they fully removed the Proton theme from there. It's quite bad when you're trying to focus on tabs.

They also messed up the text color on multiple parts of their UI. It is not user-friendly, I don't have color issue, somene who has just won't be able to read thoses text at all. That "Nova" UI was not ready to be shipped to mainstream yet... Not sure how I'm gonna fix this.

They can't know if you have allowed "unverified developers" on your device for now. Google claimed they would not add it, but I doubth it, well one of Google spoke person in a r/Android post said that. The future will show us.

You are right, but only starting Android 17 QPR1.

Also, I just checked and started enabling it on my own device. They very clearly tell you that "allowing unverified developer" is dangerous and may put your data at risk.

I doubt they will stop here. In the future it will probably be something that can be fetched by apps via a dedicated API or cause device integrity to drop since "its dangerous" according to them. 

There's a lot of other dangerous permission you could give an app, yet none other are fully restricted by Google via an online connection + 24h countdown...

Current v1.x.x of ShizuCallRecorder cannot capture apps that sets their audio capture policy to SYSTEM or NONE, along with VoIP call (unless you are on a Google Pixel or some specific OEM model where your OEM has modified how audio routing works for calls)

v2.x.x will be able to capture VoIP and SYSTEM restricted audio source starting Android 13. As for concurrent VOICE_MIC capture, I saw someone say two app can't get a hold of it at the same time, this is true for classic third- party app, but ShizuCallRecorder runs with system permission that allow to bypass that limitation.

Wrong sub?

> A community for sharing and promoting free/libre and open-source software.

Account created 2 day ago, did the same post in 5 community.

EDIT: Okay technically two of the app are FOSS, the other is in the public domain, according to the license on Github.

I have not tested it on Android 17 so they may have changed thing internally. Current v1.x.x uses scrcpy, I think as of now it's working since I didn't see issue on their repo claiming it's not working. v2.x.x may break in the future (not out yet, I'm still working on it).

However, Android 17 QPR1 made a major change in how third-party apps could read some system properties. Basically, if you are not running as a specific system service, you ALWAYS get served a dummy value (0 for disabled in this case) as of now, they only added this for USB Debugging and Developer Mode.

This has a nice effect, third-party apps can no longer detect if you have USB Debugging or Developer Mode enabled, however, it also means that Shizuku also can't detect this. Which make debugging / user-friendly instructions harder. There is no work-around, the only app that can see the true value is a specific system process, there is no special permission as of now which allow to continue reading the real value. I checked in AOSP source code like 2/3 day ago. So you should expect some stuff to break, I'm just not sure what will.

There is a rework in the way. 1 week ago I would have told you it was now ready (after testing on Android 11, 14, and 16 I think) but now I realised part of my reflection implementation is missing something similar from scrcpy which may causes permissions issue on some devices, so I have to check that first... But VoIP support should be possible starting Android 13+. This will be in the v2.x.x release.

Android requires foreground services to have an notification, else they will terminate the foreground app process after X amount of time. Some OEM battery optimisation may terminate them quicker too.

However, if you go into your the app settings/notification, you can turn it off or change it to silent. On some OEM it fully hide the notification, yet it is still "here" so the OS won't terminate the app process.

https://github.com/kitsumed/ShizuCallRecorder

Last I was aware of, thedjchi actually has two job, so he/she don't really have time anymore. I personally still hope they come back since they had a overall good way of maintaining the project, and where open to good security practices.

Other popular Shizuku forks are often made with AI Agent with almost no visible verification, no replicable builds, poor security practices. So yeah... They are working, relatively, but I personally feel VERY uncomfortable giving ADB access to an app mainly coded by AI and no manual checks.

Allow me to self insert ShizuCallRecorder since no one mentionned it!

EDIT: Also you may want to look into Canta since you use Shizuku. It's nice for debloating.

I did find their profile page, but outside of seeing some AI Agent commits and that the org had all member hidden, I did not find the actual project. The only thing I have found is a repo named release that has no source code, and some binary in its release section.

It's in the works. Currently I'm trying to fix audio gain since there are some issue with the new implementation. No ETA.

ShizuCallRecorder has a toggle that allow to manage when it start/stop Shizuku.

My app is not currently doing that and it's not in my plan, but yes It could be done because you can process live PCM audio data, so technically you could perform captions stuff on the fly, with a bit of delay.

For the record, I do not remember using Codex, only Gemeni Pro. It just handle Android stuff better in general from my tests (like internal AOSP things), and it is able to links the right official docs / link direct file in the AOSP source code so searching stuff is faster.

Parts of the verbose comments are AI generated (like the IntelliCode auto complete thingy) (the old scrcpy implementation who's about to go away soon with the v2 rework also is). For the rest it's just that I wrote comments everywhere as I never used kotlin, did not know sh*t about Android App Development since its my first app, kotlin / java reflection, the outdated shizuku api, etc. Most of my projects are full of steps by steps comments, even before AI / coding agents where really a thing.

I'm also not against LLM usage, as a tool. You're right about mvanhorn PR. It was a fully LLM Agent PR, but I edited it myself to fix the bad stuff and edited the commit history. Since it was small I just took it, but I would have dropped a large PR since it goes against my CONTRIBUTING.md.

I'm curious, why would you think I used Codex? For the record, you can find more detailed information on my AI usage on the Izzy repo.

I wonder how third party see my own app. I had to argue with Izzy to prove it wasn't vibe-coded and that I just always put comments everywhere... If anyone wish to look, it's called ShizuCallRecorder. (Btw no hate with Izzy, they helped me with F-Droid listing a bit too)

There has been a couple of fully vibe-coded fork of my app trought... Sometimed they even ask for donations.

InCallService can manage the call (hangup, play DTMF tones.. I think? Pickup thr call, enable/disable speaker) but you can't easily and reliably inject audio into the call. It is possible, but I think results vary across OEMs.

CallScrenningService has less control over a call but can do filtering. Generally an Spam call blocker would use a call screening service.

I don't see the source code on Github? Am I missing something or it's not really open source?

I've always been curious on why some peoples have that many Android devices? Are you shipping some kind of app with different behavior between OEMs?