AppManager
AppManager copied to clipboard
APK Editor (RE-Build APKs and More)
Describe the feature
Basically an option to edit each part (manifest, files, data, etc.) of an app or apk/apks file, etc.
Describe the solution you'd like
It would be great if this were similar to what is seen in the APK Editor PRO app. This app has several useful features.
Describe alternatives you've considered
It would be great if this were divided into three options:
- Common Edit
- Full Edit
- Edit Data
All these options would be the same as what is seen in the APK Editor PRO. (See the "Additional context" section to learn what these options look like)
Related issues
#6, #14, #36, #116, #165, #176, #141 and #222 (There are probably more issues but I have not found them).
Additional context
APK Editor PRO features
| Feature | Description | Example 1 | Example 2 |
|---|---|---|---|
| XML File Edit | Basically the xml files of the apk can be edited (This is included in Full Edit mode) |
![]() |
![]() |
| Common Edit | Basic parts of AndroidManifest.xml can be edited (This is included in Full Edit mode but still worth having a separate tab for this) |
![]() |
|
| Simple Edit | Just an option to replace the apk files (This is included in Full Edit mode) |
![]() |
|
| Full Edit (Resource RE-Build) | In this option everything can be changed, from AndroidManifest.xml to .smali files. It is possible to edit the file codes, replace them, delete them, edit permissions, etc. |
Full Edit home 1 ![]() |
Full Edit home 2 ![]() |
| Manifest Editor | Anything from Manifest can be changed here (A piece of Full Edit mode) |
![]() |
|
| Permissions Editor | This is in the manifest editor tab (A piece of Full Edit mode) |
![]() |
![]() |
| Strings Editor | Strings of any language can be edited and other strings can be added (A piece of Full Edit mode) |
![]() |
|
| Smali Editor | Edit .smali files (A piece of Full Edit mode) |
![]() |
|
| Edit Data (Root) | Edit database, preferences, etc. of already installed apps | ![]() |
Developement Info
Features (In the order of implementation):
-
[x] 1. [Added via a6a21a0] ~~Signing apk: For edited apks, signing with a key is mandatory. But many people wants to sign existing apks as well (there will be an option in settings for that). AM will allow user to use their own signing keys instead of just the test keys.~~
-
[x] 2. Explore apk: Basically see and explore through the apk files.
-
[ ] 3. Decompile apk: An option to decompress the resources and the dex files and save them in a specified location. There will be a meta file along with the files which can be used to recompile the project again.
-
[ ] 4. Recompile apk: After editing the files with the editor of your choice, you can recompile the project by importing it.
-
[ ] 5. Manifest editing: Option to edit the app manifest.
-
[x] 6. Smali editor: A text editor will be added to allow users to edit the smali files.
-
[ ] 7. Resource editor: A slightly advanced editor to edit resource files.
Tools (There will be some one-click special tools):
-
[ ] 1. App cloning: Changing package name in one click. Unfortunately, this will not work for apps that doesn't use unique names for
authority. -
[ ] 2. Remove tracker components: Removing the tracking signature from the App Manifest. This may result the app to crash.
-
[ ] 3. Remove app permissions: Since normal permissions can't be removed, this is the only way to remove these permissions.
Future Plans (May never see daylight!):
- [ ] 1. Support for patches: Apart from the patch schema developed by the author of APK Editor, AM can store patches for the apk files (using version control system such as git) to allow users to apply them again in future. This could be helpful (but not always reliable) for the modified apps if they need an update, in which case AM will decompile the apps, apply the previously saved patches, compile and sign them before displaying the install screen. This way the user doesn't have to skip updates.
Mostly, if not completely covered by #6 but this app's UI paradigms could really come in handy
I think it's completely covered by #6. With the introduction of bundled apps, thinks are a bit complicated though (such as all splits have to be signed with the same signing key, etc.). Adding support for APK editing is a quite complicated task and it would be better if somebody listed the features supported by the APK Editor.
One other complication is that the open source APK editors such ApkTool, jadx, are not completely free software as they use prebuilt jar files (APK Editor, etc. are using these projects, therefore, they also have it) without any build instructions. I have no idea how I can compile Android.jar file (I never really worked on Android ROMs). I want to make sure that AM always remains a free (as in libre) software so that it won't die away when I'm not around here to continue its development, and this significantly hinders my efforts. If anybody can figure out how to build Android.jar file, then and only then I can proceed.
In the mean time, I will add support for signing APK files.
@MuntashirAkon Got it, I also think it's okay if these features aren't added or worked only in the future, mainly because of the complexity that would be working on it. Besides, as the issue #6 cover this issue, I'll close it now. Thanks for the reply and thanks for your work.
#6 is already closed since it contained too many off-topic comments.
Yes, it'd be nice if AM could repack .apks/.apkm/.xapk/.zip(.apks) to a universal .apk.
Yes, it'd be nice if AM could repack .apks/.apkm/.xapk/.zip(.apks) to a universal .apk.
It is possible using the bundletool. But we need a more cleaner solution. Because if this is going this way, the app size of AM would be around 50 MB when installed.
Yes, it'd be nice if AM could repack .apks/.apkm/.xapk/.zip(.apks) to a universal .apk.
It is possible using the
bundletool. But we need a more cleaner solution. Because if this is going this way, the app size of AM would be around 50 MB when installed.
Why size would matter? An app that can do anything related to an app would surely have some weight.
Why size would matter? An app that can do anything related to an app would surely have some weight.
It matters because not all people are going to use this feature, including myself (why would I need an apk converter when bundled app works on my phone?). Even if somebody uses the feature, it's very unlikely that s/he's going to use it everyday. Also, you've have to consider the people who do not have enough storage (like myself). Cost-benefit relationship is an important issue when it comes to developing an app.
Why size would matter? An app that can do anything related to an app would surely have some weight.
It matters because not all people are going to use this feature, including myself (why would I need an apk converter when bundled app works on my phone?). Even if somebody uses the feature, it's very unlikely that s/he's going to use it everyday. Also, you've have to consider the people who do not have enough storage (like myself). Cost-benefit relationship is an important issue when it comes to developing an app.
Hmm, then how about having a separate app as APK editor? I know there already exists one but it's missing many features.
Hmm, then how about having a separate app as APK editor? I know there already exists one but it's missing many features.
No, that would introduce the Xy problem. It's better to solve the real problem instead.
APK editor is not currently possible because of the reason I've stated above. Android.jar, aapt, aapt2 are the three requirements for the APK editor and unfortunately, I don't know how to build Android.jar.
It looks like I've found a way to compile android.jar.
Features (in the order of implementation)
- Signing apk. For edited apks, signing with a key is mandatory. But many people wants to sign existing apks as well (there will be an option in settings for that). AM will allow user to use their own signing keys instead of just the test keys.
- Explore apk.
- Decompile apk. An option to decompress the resources and the dex files and save them in a specified location. There will be a meta file along with the files which can be used to recompile the project again.
- Manifest editing. Option to edit the app manifest.
- Recompile apk. After editing the files with the editor of your choice, you can recompile the project by importing it.
- Smali editor. A text editor will be added to allow users to edit the smali files.
- Resource editor. A slightly advanced editor to edit resource files.
Tools There will be some one-click special tools:
- App cloning. Changing package name in one click. Unfortunately, this will not work for apps that doesn't use unique names for
authority. - Remove tracker components. Removing the tracking signature from the App Manifest. This may result the app to crash.
- Remove app permissions. Since normal permissions can't be removed, this is the only way to remove these permissions.
Support for patches This is just a future plan, it may never see daylight!
Apart from the patch schema developed by the author of APK Editor, AM can store patches for the apk files (using version control system such as git) to allow users to apply them again in future. This could be helpful (but not always reliable) for the modified apps if they need an update, in which case AM will decompile the apps, apply the previously saved patches, compile and sign them before displaying the install screen. This way the user doesn't have to skip updates.
Apart from the patch schema developed by the author of APK Editor
In case this gets implemented, support for Lucky Patcher's patch schema would be beneficial since LP already has tons of patches for popular apps
In case this gets implemented, support for Lucky Patcher's patch schema would be beneficial since LP already has tons of patches for popular apps
Do they have any patching guide that I can follow (like APK Editor does)?
Apart from the patch schema developed by the author of APK Editor
In case this gets implemented, support for Lucky Patcher's patch schema would be beneficial since LP already has tons of patches for popular apps
And most of those patches are used to crack apps. Lucky patcher has bad reputation among app devs because of the same reason.. The day won't be far if AM implement something like that and get flagged by Play Store Protection as malicious.
Any app related to high-level apk editing is marked as malicious by Play Store. Even App Cloner, (the app they made a fortune from) was banned from GP. But I do agree, most Dev would blacklist AM too if it starts that kind of high-level apk editing. Heck, they even blacklist Adblockers.
And most of those patches are used to crack apps. Lucky patcher has bad reputation among app devs because of the same reason.
I agree. AM isn't a software for cracking apps. But it will definitely provide features like APK editing because it gives users freedom as well as privacy. Patch schema used by APK Editor is just a shorthand for lengthy, boring tasks. So, it won't be a problem. I don't know what the state of LP is now (I haven't used it in years) but there are valid reasons for it to be flagged as malicious:
- It's sole purpose is hacking/cracking an app
- It's a closed source app with extensive obfuscation (you cannot understand what it does simply by decompiling it)
- It provides run-time patching for apps instead of modifying the APK itself which is a major violation aka "cracking" since the APK itself is signed by the author of the app.
AM will only modify the APK file which has to be signed by either a public/generic key or by a custom key. It means it would respect the signature verification methods if the author of the app implemented such features with sufficient obfuscation (using Proguard or Dexguard) so that a person with malicious intention won't be able to modify it. The app can also supply a EULA to forbid the users from modifying the APK in which case if the app is modified and distributed, the app authors can take legal actions against the user but AM won't be responsible for it because by using AM the user has already consented that neither AM nor I, the developer, will take any responsibility for the user's action.
Even App Cloner, (the app they made a fortune from) was banned from GP.
App Cloner violated GP policy which is why it got deleted from the store. It's not marked as malicious app. APK Editor, which also violated GP is in the play store because it complied with the policy by removing the features that allowed changing app contents.
Signing APK files before installing is added via a6a21a03
@MuntashirAkon I just realized that I did not quote these features of apk editor in this issue:
And within these options is the option to edit the signature key:
I think this is a feature that can be very useful for many people.
@RickyM7 Read the point no. 1 again. It reads like this:
But many people wants to sign existing apks as well (there will be an option in settings for that). AM will allow user to use their own signing keys instead of just the test keys.
Read the point no. 1 again. It reads like this:
@MuntashirAkon Of course, I'm sorry, I just edited this part and I didn't remember. Anyway, there is a simple design example that you can use for this feature if you want.
Anyway, there is a simple design example that you can use for this function if you want.
AM will have more options than this including the most widely used Java KeyStore (JKS). AM will also support creation of signing keys rather than just importing them.
AM will have more options than this including the most widely used Java KeyStore (JKS). AM will also support creation of signing keys rather than just importing them.
That's really great. Changing a little the subject, I think the AM crashed on my phone because of the new apk signature feature. Can I send the crash log here or should I create a new issue?
Can I send the crash log here or should I create a new issue?
Create a new issue.
@MuntashirAkon I added the "Edit Data" feature in Additional context (last feature of the list). This feature is for rooted users only and so I ended up forgetting to add it before.
I added the "Edit Data" feature in Additional context (last feature of the list). This feature is for rooted users only and so I ended up forgetting to add it before.
Possible duplicate of #14, shared preferences can already be edited.
It looks like I'm going to implement 5 before 4. So, 5 (recompile) should come before 4 (manifest editing).
APK Explorer & Editor gets supporting dex decompilation(to smali) https://github.com/apk-editor/APK-Explorer-Editor/commit/cfff6474463cfbf632f335a9c99ac67737378c83
APK Explorer & Editor gets supporting dex decompilation(to smali) apk-editor/APK-Explorer-Editor@cfff647
It's not difficult to implement a feature, planning is. Incorporating a new feature to the existing ones is the most difficult task. That's why the steps were chosen very carefully and will be proceeded that way.
That being said, there's already an open source (but GPL-2.0 licensed) app available called Apktool-Android which has many features, but for some reason, the developer stopped working on it.











