Repository navigation
Porting jadx to HarmonyOS NEXT PC via embedded JVM - Courtesy notice & name check #2967
Replies: 2 comments 1 reply
|
Hi @skylot , following up on my own post here. The HarmonyOS NEXT PC port already works end to end, the engine runs unchanged, and i have documented the whole build process. so honestly most of the groundwork is already done. bringing jadx to HarmonyOS PC (and eventually AppGallery) wouldn’t take much effort on your side. the platform is rolling out overseas now and jadx is popular enough that there’s a real audience for it there. As a Huawei developer, If that’s something you’d be open to exploring, i am glad to do the heavy lifting: testing on real HarmonyOS hardware, keeping the port in sync, and acting as a bridge to the chinese HarmonyOS teams I just need a channel to reach you. could you share an email or whatever works best? Thanks for jadx. |
@afk59 nice work 👍
Not sure what you mean, but I was hoping that someone else will maintain this port
Sorry, I don't want to share my email, just post everything right here. |
Uh oh!
There was an error while loading. Please reload this page.
jadx ported to HarmonyOS NEXT PC
Hello, and thank you for jadx.
This is a courtesy heads-up rather than a bug report. I have ported jadx to HarmonyOS NEXT PC, a platform without a standard Java runtime or desktop window toolkit, and I wanted to let you know about it directly.
What I did
The jadx decompiler engine itself is not modified. I did not patch the jadx source or modify the Maven artifacts.
jadx-coreand the input plugins are consumed from Maven Central as published, and they run on an embedded BiSheng JDK 17 (aarch64, musl) inside the application package.What I replaced is the interface. The
jadx-guiSwing UI cannot run on HarmonyOS NEXT, so I wrote a new frontend using the platform's native language and UI framework (ArkTS/ArkUI). It communicates with the engine through a small native bridge:The bridge currently exposes
open,tree,code,search,usage,status, andclose, using JSON for communication.Measured on a real device
The
java.desktopresult was particularly useful. With resource decoding enabled, across two real APKs, the engine did not load any classes from that module. This allowed us to omit it from the runtime image.The main AWT-related path we found in core is
Res9patchStreamDecoder. It was not triggered in our test cases, and the application handles its absence gracefully rather than shipping the entirejava.desktopmodule.License and attribution
I have tried to keep the distribution and attribution requirements explicit:
LICENSEfile includes the applicable license text.NOTICEidentifies this as a modified distribution and points to the original jadxNOTICE, including the third-party and AOSP-related components.jadx-gui; their JetBrains origins and applicable licensing are documented indocs/ICONS-NOTICE.md.docs/THIRD-PARTY.md.I would appreciate it if the jadx maintainers could point out anything in this distribution that should be changed from a licensing, attribution, or redistribution perspective.
Where it is
https://atomgit.com/OpenHarmonyPCDeveloper/ohos_jadx
The project is published in the HarmonyOS PC developer community. The repository includes the build scripts, runtime module list, permission and signing steps, and notes about the issues encountered during the port.
The main goal was also to document the process so that others attempting to bring Java applications to HarmonyOS NEXT PC do not have to rediscover the same problems.
Happy to provide more details or make changes if anything in the port or its distribution should be handled differently.
All reactions