app support

[venkat2305]

revanced supports these apps. please add them

https://play.google.com/store/apps/details?id=net.binarymode.android.irplus
https://play.google.com/store/apps/details?id=com.dci.dev.androidtwelvewidgets
https://play.google.com/store/apps/details?id=com.microblink.photomath
https://play.google.com/store/apps/details?id=io.yuka.android
https://play.google.com/store/apps/details?id=com.teslacoilsw.launcher

[nikhilbadyal]

Added irplus. Will keep the issue updated.

[IMXEren]

This app was also added:

https://play.google.com/store/apps/details?id=com.laurencedawson.reddit_sync
https://play.google.com/store/apps/details?id=com.laurencedawson.reddit_sync.pro

Note: Currently, Sync Pro doesn't seem to work, only the regular sync app. Plus, I don't think someone would find a genuine public source for Pro as it's paid so, it needs to be used as EXISTING_DOWNLOADED_APKS

It includes a patch named change-oauth-client-id as stated in this reddit post.

To use this patch, you must provide a client ID. Create the file /data/storage/emulated/0/reddit_client_id_revanced.txt (in your internal storage) with the client ID as its content. Alternatively, you can provide the client ID using patch options.

So, I tried and succeeded in adding Sync for Reddit (base) from apkmirror source but the only thing fails the patching is the change-oauth-client-id patch. It requires me to hardcode the client id in the options.json file to patch it which I don't consider secure. The syntax is:

{
  "patchName" : "change-oauth-client-id",
  "options" : [ {
    "key" : "client-id",
    "value" : "REDDIT_CLIENT_ID"
  } ]
}

What are your opinions on this?

[Spacellary]

I believe this is very pertinent, the matter of the Sync change-oauth-client-id, as having it raw in the patch options isn't ideal or safe, perhaps if patch options.json were a Secret?

[nikhilbadyal]

Hey @IMXEren thanks for the info.
As for the solution, @Spacellary idea looks nice. Will provide an option to inject into client-id into options.json from actions. Completely moving options.json to secret might not that good. We can keep it public but the GitHub Action will inject client into options.json while building.

[Spacellary]

Possible to also support RVX Reddit?

[Spacellary]

Sync hype sync hype.
Is the Client Auth secret for Reddit_Sync gonna be possible to implement?

[nikhilbadyal]

@Spacellary @IMXEren

Added the ability to patch reddit clients. Provide REDDIT_CLIENT_ID as a secret. See the last point in README.md.

Let me know if it does/n't work.

[Spacellary]

@nikhilbadyal

Synced repo to ustream, testing...

There are two situations happening to me:

1. "reddit_sync" is an invalid application to patch:
   https://github.com/Spacellary/ReVanced-Extended-Automated-Builds/actions/runs/5547096072/jobs/10128261445#step:6:128

That was the entry I had before, but then...

2. Using "sync" instead results in Invalid app from the downloader.
   https://github.com/Spacellary/ReVanced-Extended-Automated-Builds/actions/runs/5547038458/jobs/10128122671#step:6:127

Looking at config.py it seems to be named "sync ", with a space? Same for the other clients.

Trying to patch 'sync ' results in Invalid app requested to build sync :
https://github.com/Spacellary/ReVanced-Extended-Automated-Builds/actions/runs/5547177349/jobs/10128450185#step:6:144

[Spacellary]

Removing the extra spaces resulted in successful patch.

I have another issue, trying to specify the compatible version, using SYNC_VERSION=v23.05.03-17:18 but the lastest version is still the one being downloaded:
https://github.com/Spacellary/ReVanced-Extended-Automated-Builds/actions/runs/5547273821/jobs/10128688277#step:6:123

Never mind now it worked. Seems fine now in that aspect.

Now there's just the invalid character to fix in the artifact:
https://github.com/Spacellary/ReVanced-Extended-Automated-Builds/actions/runs/5547403919/jobs/10129004133#step:7:16

Which is already in this PR, when you can merge or use a different implementation ofc.

Using this PR it worked perfectly for me aswell.

[Spacellary]

Only one issue left I'd say, I used EXCLUDE_PATCH_SYNC=Disable ads in my .env and the patch was still applied. ^^')

[IMXEren]

Only one issue left I'd say, I used EXCLUDE_PATCH_SYNC=Disable ads in my .env and the patch was still applied. ^^')

Haven't tested yet. Will sync and report the outcomes tomorrow.

[nikhilbadyal]

@Spacellary

1. There was an extra space which was removed in this commit.
2. Invalid chars in the File name. Fixed that in this PR. See this too.
3. You can keep on excluding the patches same old way like so it should be EXCLUDE_PATCH_SYNC=disable-ads

[Spacellary]

@nikhilbadyal thanks for addressing these!

Sorry if the question is unnecessary but... Is there a reason why some apps have spaces in their names in config:

Namely infinity, slide and bacon...?

[nikhilbadyal]

Thanks for pointing out @Spacellary .
Mistakenly added spaces. Fixed by this.

[Spacellary]

@nikhilbadyal
I believe everything is alright now, my fork is up-to-date with upstream and I'll just wait for @IMXEren own tests, but on my end this is pretty sweet. Eren has added in the MicroG support by the way, if you'd like to follow up on that perhaps?

[IMXEren]

3. You can keep on excluding the patches same old way like so it should be EXCLUDE_PATCH_SYNC=disable-ads

Okay, I'd say this can be a hectic task for new users. FYI, revanced/revanced-patches have moved their patch table to their official site and the patches there use the newest convention. If somebody wants to use them, they might have to go through all that editions to exclude their patches. Currently, I don't find any patch names with commas (,), so I don't think invalid patch issue can occur.

Does using the newer convention, can cause conflicts? I specifically propose to also allow newer patch names in envs. I don't consider anything for older convention.

Also, to add, I haven't/can't test if inotia00/revanced-patches support both conventions as you can still see the older table but newer convention in patches.json.

I believe everything is alright now, my fork is up-to-date with upstream and I'll just wait for @IMXEren own tests, but on my end this is pretty sweet. Eren has added in the MicroG support by the way, if you'd like to follow up on that perhaps?

@Spacellary, here's the PR #218.

[nikhilbadyal]

Does using the newer convention, can cause conflicts?

No, it doesn't. The new convention is more readable. One issue I have with the naming convention is the spacing itself. Spaces are very easy to miss and can introduce errors. For example, it's easy to confuse Hey There with Hey There.
Extra spaces can be easily overlooked. Whereas with the ids convention, it is going to be "hey-there" or "hey--there," in which the extra "-" is easily identifiable.

@IMXEren , Your opinion ?

[IMXEren]

No, it doesn't. The new convention is more readable. One issue I have with the naming convention is the spacing itself. Spaces are very easy to miss and can introduce errors. For example, it's easy to confuse Hey There with Hey There.
Extra spaces can be easily overlooked. Whereas with the ids convention, it is going to be "hey-there" or "hey--there," in which the extra "-" is easily identifiable.

@IMXEren , Your opinion ?

This can be a valid point but still renaming thing can't be overlooked. For example, let's say your repo very much appealed to a user. They read everything in your README.md. But still they face errors when patching. You know, people with less technical understanding always blaim the devs, play store apps review as example. Now, if you implement the newer convention, you know that they may do typos but still they can't blaim you for it. May be also include the typo thing in README.md if you do implement the newer patch names.

Lastly, even though it'll require me to do the same, I'll just use the Tasker integration with your repo or forked repos to do this part for me. I apologise if I sounded rude.

[Spacellary]

I agree on going for the new convention for all apps.

It's less prone to user's errors and again they can't blame the project for being obtuse.

[nikhilbadyal]

Closing the issue this as all the apps are supported now.
Also converting this into discussion.

[Spacellary]

@nikhilbadyal I have changed my mind. But I'm conflicted, so inotia00's reasoning for keeping his ReadMe with the old convention is because that's the accepted by the CLI.jar, which I agree is a good reason.

In that sense I prefer to use the old convention with the hifens, as I also think spaces don't belong there or in file names.

For that reason, for what matters, I am a proponent for the names-with-hifens as they are.

@IMXEren thoughts on inotia00's reasoning?

[IMXEren]

@Spacellary

1. I didn't like the newer convention. Readable? Yes. CLI friendly? No.
2. Why wanted to have it? Simply to have a synchronised repo with RV(X) updates.
3. I didn't want to discard the support for older conventions but to be able to also use newer.

Again, Not much of a deal for me. Whatever dev chooses in the end is fine by me. And based on the current README.md, it's older and mentioned in it.

[IMXEren]

I mean they could've come up with patch ids along with those.

Agreed, breaking the scripts just for mere convenience, isn't a good idea.

[nikhilbadyal]

We can support both. Maybe something like this.

While parsing excluded patches if any patch contains - we can conclude the user is using an older convention otherwise new.

But if ever implemented it will be done when both Revanced & Extended support both kinds of patching.

[Spacellary]

Well then so for now the old convention is what to go for, so should I just keep teaching people using the old convention and not bother with the new weird one?

[IMXEren]

I'd like to confirm this too.

But if ever implemented it will be done when both Revanced & Extended support both kinds of patching.

Sorry didn't notice this.

Now, then it's old for the time being.

[nikhilbadyal]

Yes , old for now.

[IMXEren]

Hey @nikhilbadyal , sorry for disturbing again. I noticed some things for app sources in src/config.py so, thought of mentioning them to you. Ignore if they assert some significance.

1. candyvpn - L34, 79
   • Reason: dual sources; prefer APKM
2. twitch - L27, 68
   • Reason: dual sources; prefer APKM
3. meme-generator-free - L29
   • Reason: uptodown source while APKM source present
4. yuka - L30
   • Reason: uptodown source while APKM source present
5. facebook - L31
   • Reason: uptodown source while APKM source present

[Spacellary]

Inotia might remove MicroG support.

Sharing an issue that might be of interest:

inotia00/ReVanced_Extended#1207

[Spacellary]

@nikhilbadyal @IMXEren I'd say to share your thoughts on it as well, at least all options are accounted for if it's inevitable.

[IMXEren]

Oh :(

As I read the issue, I infer it's due to many sources which makes the patches incompatible. Why not simply set the target source and version (as you do ask)? It's also not that inotia00 doesn't provide his flavor of MicroG.

For this repo, I'd vote to let it remain in the code for some time (1-2 months). Maybe the patch returns. Also, after the patch removal, it won't be patched. Will it? If not, can simply comment out microg in src/config.py.

@Spacellary @nikhilbadyal

Thanks for letting us know.

[Spacellary]

Why not simply set the target source and version

Yeah...

[nikhilbadyal]

We will still keep the code for patching microg. I hope it's a temporary suspension.

[Spacellary]

For the record:

feat(microg): temporary suspension of support for all patches: inotia00/revanced-patches@03b9875

[Spacellary]

This won't affect support as the patches will still be relevant for the foreseeable future but it is what it is...

feat(youtube): preparation for discontinuation

[nikhilbadyal]

Saw the drama in the rvx lite channel. Sad to see the project being discontinued but as you said it is what it is.

[Spacellary]

Official ReVanced Extended Discontinuation Announcement and Closing Words by Inotia00.

https://github.com/inotia00/revanced-documentation/wiki/Announcement

Of no concern for the time being, but something to watch for the coming months as patches become disfuncional with breaking changes.

[Spacellary]

*@nikhilbadyal

I've been watching these, was also gonna comment to you about them earlier today, but I figured I'd should just wait and watch for more development, and the possibility of the author incorporating new Spoofing fixes either his own (he said he has been looking into it, with no success tho) or incorporating from up-upstream, once the RV-Team fixes it.

But hey, that's why the Custom Resources feature was implemented, it's now easy to use any patches even your own local repo files ❤️

Won't ask for it but kinda referencing again the viability of patching totally custom applications as well, just to make the tool totally independent/future proof.

[nikhilbadyal]

I already have it in my mind. But Now sure when though.

[nikhilbadyal]

It's supported now. You can patch any application with the tool. See example env here and docs here

[IMXEren]

Btw, what'll be to replace the APP_NAME placeholder?

Probably, an arbitrary valid upper-cased string which doesn't associate with the official repository packages.

[nikhilbadyal]

what'll be to replace the APP_NAME placeholder?

Anything (upper cased) , other than the supported app names.

See the .env.example file where I'm building YouTube Revancify Red.

[Spacellary]

@nikhilbadyal
Not an issue yet, so I didn't think to open an issue and just used this discussion to comment on it if that's alright, but, I just noticed when using the new pre-release versions of the ReVanced/revanced-cli locally, -a is no longer being used to specify the target APK for patching, instead the patch command is used, it used to be:

java -jar cli.jar -a duolingo.apk -b patches.jar...

...but now it is:

java -jar cli.jar patch duolingo.apk -b patches.jar...

This is gonna cause issues when patching with the official ReVanced CLI in their next stable ReVanced/revanced-cli release if it reflects their pre-release changes so far. It will cause a divide since RVX/ReX use the previous structure, so the command isn't gonna be universally the same just with different resources anymore.

[nikhilbadyal]

Ah, Another episode of making life harder.

I think they should support both, -a as a smaller alias for the new patch option.

Hope all the fork maintainers update their fork. I don't see any elegant way to support both types of patching.

[IMXEren]

Yeah, I too don't understand these new changes. If a user is using the CLI, I believe that they must be aware of that environment and don't have problems with basic complexities.

Just like Patch naming wasn't necessary and a possible worst decision, this too falls under the same category.

The last resort is that YT-Adv must fork inotia00's cli and push necessary changes to that because there's no api or data set to determine what the CLI arguments are.

[Spacellary]

I think they should support both, -a as a smaller alias for the new patch option.

This at the very least. Think we are able to open an issue at least to ask for keeping -a as a short alternative to the patch command?

It's honestly such a pointless change, I don't understand the reason of half of the stuff oSum and the core team do, and the other half I just disagree...