Development stalled?

[GrabbenD]

Looks like the community is very active and putting a lot of effort into solving open issues, especially @AnonymousWP judging by the massive amount of pull requests from his side. However, the main project seems stale as there haven't been any new releases since July of last year.

Perhaps it be worthwhile to add more maintainers to push the main codebase forward since we shouldn't expect one man (@0x192) to carry this project?

[GrabbenD]

In the meantime, @AnonymousWP do you possibly have a active fork of this which encapsulates all open PRs in a up to date branch until PRs starts getting merged here? Just got a new phone and I'm really grateful this project exists, I'd love to benefit from all the latest work in PRs section :)

[BUZZARDGTA]

UP

[AnonymousWP]

In the meantime, @AnonymousWP do you possibly have a active fork of this which encapsulates all open PRs in a up to date branch until PRs starts getting merged here? Just got a new phone and I'm really grateful this project exists, I'd love to benefit from all the latest work in PRs section :)

I've been thinking about that, and I'd love to, but it wouldn't help as I'll have to compile the code and release the application myself. I don't have Rust knowledge. This is required, because if I just merge the PRs, then the program still points to this repository for downloading the UAD file instead of my repo.

Feel free to give me suggestions and I'll see what I can do. 🙂

[shuvashish76]

@AnonymousWP that's great, thanks for being active here. I hope someone continue this project.

do you possibly have a active fork of this which encapsulates all open PRs in a up to date branch until PRs starts getting merged here?

FYI : We've ADL which currently works with AM from the same developer. Would be nice if we could start merging open debloater PRs there.

[Blitz517]

there's more open issues than closed 👀

[AnonymousWP]

@AnonymousWP that's great, thanks for being active here. I hope someone continue this project.

do you possibly have a active fork of this which encapsulates all open PRs in a up to date branch until PRs starts getting merged here?

FYI : We've ADL which currently works with AM from the same developer. Would be nice if we could start merging open debloater PRs there.

Nice one! However, I'm afraid it's not easy to merge my +50 PRs that easily. Maybe I can open an issue to ask and so we can push my stuff directly to that repo. 🙂

[VeH-c]

I have offered to be a package maintainer https://github.com/0x192/universal-android-debloater/issues/715 I think @AnonymousWP would be a good candidate. Ultimately we should learn the skills, fork the project and continue without @0x192 , like https://github.com/MuntashirAkon/android-debloat-list maybe then we could find a way to work with him when/if he becomes active again.

[shuvashish76]

I have offered to be a package maintainer #715

The owner needs to active here in the 1st place to give you a reply.

Ultimately we should learn the skills, fork the project and continue without @0x192 , l_ike https://github.com/MuntashirAkon/android-debloat-list_

Maintaining bloatware packages is not an issue, those can be reviewed by anyone with minimal effort as it doesn't involve any real code. Active development related to UAD software itself should be the main concern here. In ADL case the lists are kept separately from the software (AppManager) on which it works.The advantage of that project is it works on your same (Android) platform.

[jxdv]

bump

[jxdv]

It'd be great if anyone with good enogh Rust knowledge would fork and start working on this. I know we're a bunch of people here who care & want to see UAD with all these issues / PRs finally resolved & closed.

PKGs could be fetched from (as above mentioned) ADL.

UP UP UP

[Rudxain]

anyone with good enough Rust knowledge would fork and start working on this

I could help, but, isn't the whole point to use an alternative rather than UAD? Why "resurrect" UAD?

[jxdv]

anyone with good enough Rust knowledge would fork and start working on this

I could help, but, isn't the whole point to use an alternative rather than UAD? Why "resurrect" UAD?

I don't see any problem with "resurrecting UAD" -> We already have a decent working GUI, and most of the PRs here are mostly pkg additions, and there's no problem finding active people here who'd work on all of that.

Rust is a good language choice as we have cross-platform binaries, so I don't think there's any point in building something new from scratch, but these are just my thoughts.

[Rudxain]

We already have a decent working GUI

It could be better, but I agree.

and most of the PRs here are mostly pkg additions, and there's no problem finding active people here who'd work on all of that.

Yes, but (as others explained earlier) we can "move" those PRs to ADL.

Rust is a good language choice as we have cross-platform binaries

Wait, I have an idea. It's possible to implement ADB protocol via WebUSB (and perhaps even WebRTC, for ADB over TCP/IP). So we could make a PWA. The only downside is that WebUSB isn't truly cross-platform, as Firefox refuses to implement it until W3C writes a safer spec. Chromium browsers support it though.

building something new from scratch

I agree we shouldn't "reinvent the wheel", but that's not what I meant. I meant to use AppManager as alt, and contribute to both ADL and AM. Although we could continue to keep UAD alive, and that's fine too.

BTW, I'm kinda concerned about @0x192 . Has someone managed to contact him? Is he active on other platforms? (I've checked his GitLab, but recent commits are by bots) Is he busy IRL? Is he burnt-out and/or depressed? :(

[jxdv]

Yes, but (as others explained earlier) we can "move" those PRs to ADL.

Yeah makes sense, and it would most likely be even better. PKG contributions would be addressed in ADL while the core code logic would live in our "new uad". So we would split the project in two as you've already discussed.

Wait, I have an idea. It's possible to implement ADB protocol via WebUSB (and perhaps even WebRTC, for ADB over TCP/IP). So we could make a PWA. The only downside is that WebUSB isn't truly cross-platform, as Firefox refuses to implement it until W3C writes a safer spec. Chromium browsers support it though.

I am not really knowledgeable in those technologies but it sounds interestings. I'll definitely look into this.

I agree we shouldn't "reinvent the wheel", but that's not what I meant. I meant to use AppManager as alt, and contribute to both ADL and AM. Although we could continue to keep UAD alive, and that's fine too.

AppManager is a great app, but it is much more heavyweight than UAD, and I liked the fact that this was specifically just for debloating your phone. No other bs involved, and already had a support for so many platforms.

BTW, I'm kinda concerned about @0x192 . Has someone managed to contact him? Is he active on other platforms? (I've checked his GitLab, but recent commits are by bots) Is he busy IRL? Is he burnt-out and/or depressed? :(

Unfortunately I've started contributing after the development was already stalled, but yeah it would be nice if anyone who knows him contacted him, even better if he gets active again, but we don't know his situation :/

[Rudxain]

I am not really knowledgeable in those technologies but it sounds interestings. I'll definitely look into this.

I recommend searching "WebADB". There's many implementations! (I'm surprised)

AppManager is a great app, but it is much more heavyweight than UAD, and I liked the fact that this was specifically just for debloating your phone. No other bs involved

I'm a minimalist, so I approve that, haha.

Unfortunately I've started contributing after the development was already stalled, but yeah it would be nice if anyone who knows him contacted him, even better if he gets active again, but we don't know his situation :/

ok, I guess we'll have to wait 🙁

[shuvashish76]

AppManager is a great app, but it is much more heavyweight than UAD, and I liked the fact that this was specifically just for debloating your phone. No other bs involved, and already had a support for so many platforms.

You can't really blame AM for this since "Debloater" (currently alpha) is not even a major features of AM . As per their description

This single app combines the features of 5 or 6 apps any tech-savvy person needs!

So combining multiple relevant features natively is one of the core principles of that project.

From a minimalist point of view, use any software (even simple Android platform tools only) for debloating your android device then just uninstall them, because why bloat the PC/phone 😉 with such debloater softwares when debloating is one time job only... That's just my opinion I know users might have other reasons to keep them in their system. (e.g For my usecase I use AM profiles feature heavily, which is a limitation for PC softwares if you're in outdoor/travelling)

Has someone managed to contact him?

I tried to contract him through mail, but no replies so far :(

[Obegg]

Seems like there's a fork with many changes and additions taken from PRs on this GitHub, so it looks promising, especially the

All of AnonymousWP's patches.

haven't checked it out yet, but just thinking I should at least mention it here, https://github.com/Frigyes06/universal-android-debloater

[jxdv]

Lets see how that goes. I've opened my already existing PRs to that fork.

[Frigyes06]

Yes! I'm trying to reactivate the project! See y'all over at the fork https://github.com/Frigyes06/universal-android-debloater