Skip to content

Switch to the new Xposed API - #417

Closed
frknkrc44 wants to merge 4 commits into
JingMatrix:masterfrom
frknkrc44:switch_new_xposed_api
Closed

frknkrc44 wants to merge 4 commits into
JingMatrix:masterfrom
frknkrc44:switch_new_xposed_api

Conversation

@frknkrc44

Copy link
Copy Markdown
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
Copy Markdown
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

frknkrc44 commented Nov 9, 2025 •

Copy link
Copy Markdown
Contributor Author

@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

fatalcoder524 commented Dec 4, 2025 •

Copy link
Copy Markdown

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
Copy Markdown
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

JingMatrix commented Feb 13, 2026 •

Copy link
Copy Markdown
Owner

@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
Copy Markdown
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
Copy Markdown
Owner

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

@JingMatrix

Copy link
Copy Markdown
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
Copy Markdown
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