Skip to content

Comments

Switch to the new Xposed API#417

Closed
frknkrc44 wants to merge 4 commits intoJingMatrix:masterfrom
frknkrc44:switch_new_xposed_api
Closed

Switch to the new Xposed API#417
frknkrc44 wants to merge 4 commits intoJingMatrix:masterfrom
frknkrc44:switch_new_xposed_api

Conversation

@frknkrc44
Copy link
Contributor

It is an initial attempt and needs testing.

@frknkrc44 frknkrc44 force-pushed the switch_new_xposed_api branch from ebeb6dd to c58e7fd Compare September 3, 2025 19:46
@JingMatrix
Copy link
Owner

I heard that your motivation is to solve the compatibily with modules such as PlayStrong.

These modules are using Xposed API 100, and a related bug is fixed in ed1f61d.

Please also refer to #466 (comment)

@frknkrc44
Copy link
Contributor Author

frknkrc44 commented Nov 9, 2025

@JingMatrix No, my target was not PlayStrong module. I just tried to adapt the current API with all of new methods without killing the old version support. You can see it in the code, I didn't touched to anything about SELinux etc. and only tried to follow the new API requirements.

@fatalcoder524
Copy link

fatalcoder524 commented Dec 4, 2025

Sorry for the confusion guys!

This commit actually has 3 fixes:
ThePedroo@986abf9

  1. Support for new API.
  2. Fix Read-Write Issue when using Remote Files api.
  3. Update selinux policy of files on boot.

2-3 Fixes the Play strong issue and 1 actually is the PR submitted by @frknkrc44 to support new APIs for modules like Hyper ceiler new versions (Not sure of this claim though).

The PR here has nothing to do with Play Strong compatibility and is a standalone PR.

@JingMatrix JingMatrix closed this Dec 4, 2025
@JingMatrix
Copy link
Owner

@frknkrc44 oh, sorry, I must have closed this by accident (mis-click on the phone). When I get some time on adapting the upstream changes, I will tell you.

@VD171

This comment was marked as off-topic.

@JingMatrix
Copy link
Owner

JingMatrix commented Feb 13, 2026

@frknkrc44 Your implements of APIs invokeOriginalMethod and invokeSpecialMethod were correct, as explained in #533 .

Your handling of annotation removal is not a good solution arguable , see #534 .

However, the problem is the API change itself, not us.

@VD171

This comment was marked as off-topic.

@frknkrc44
Copy link
Contributor Author

@JingMatrix I only want to say:

  • It would be nice to keep the backwards compatibility, the API itself can change but people can want to use their old modules. That's why I tried to keep the old module support in this PR.
  • I was who did the research about this issue, spent time on it and tried to fix the issue without break anything. You kept this PR open for months, closed it without saying anything (you didn't even reached me to separate this PR into 2 pieces like you did), then wrote something about it happened accidentally, then you prepared your own code without credit my work.

@JingMatrix
Copy link
Owner

Okay, I will credit you for the part we are using the same solution.

@JingMatrix
Copy link
Owner

@frknkrc44 1. The pull-request was closed by accident, probably a mis-click.
2. Initially, I plan to do the implementation during the refactor, but few users have urged me to implement it earlier. I did my own implementations step by step last night, by checking the libxposed upstream repo commit by commit. You are right that I should credit you at the first two commits. I appologize for this, and has no intention to ignore your contribution.

@frknkrc44
Copy link
Contributor Author

@JingMatrix Thanks for force-push after crediting me, and I accept your apologize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants