to @AbdurazaaqMohammed

[drogga]

@AbdurazaaqMohammed I'm not opening an issue in your aXML Editor repo on purpose, but I've noticed the following:
The editor's text is black on a black background, so it's invisible by default, I had to change its color.
There's no ID2Name, so it's hard to know what's what.
It asks to save decoded 2 times as a .txt file, while it can be as .xml so the syntax can perhaps work...?
It caches files and sees (hallucinates) that some are on storage, while they aren't anymore and by default it opens Recent, but it should either /storage or /storage/Download.
It cripples the encoded .xml, check with Explorer or Root Explorer (Paid) by SpeedSoftware to see what I mean - it's not actually readable after the edit, for that matter anything that can edit the Manifest "directly" does cripple it that way, being "APKTool M", Lucky Patcher or even NP Manager (I think, have used it previously) and I'm not sure about the old APK Editor Pro and the mods of it, but I don't remember it doing this, MT Manager on the other hand compiles/decompiles it properly always, being the string pool edit or the full edit one, but there are lines limit and it wants VIP for the unlimited edit (unfortunately), that's why I need your tool to work better.
Thank you.

[AbdurazaaqMohammed]

The editor's text is black on a black background, so it's invisible by default, I had to change its color.

I am aware of this I will fix it in the next update

There's no ID2Name, so it's hard to know what's what.

It's not possible to do this without accessing resources.arsc in some way, it should be possible with ARSCLib, but I'm busy for now, so I won't add it for a little while

It asks to save decoded 2 times as a .txt file, while it can be as .xml so the syntax can perhaps work...?

I did this on purpose because I couldn't find a good way of checking if a file was already decoded or not. But I'll try it again

It caches files and sees (hallucinate) that some are on storage, while they aren't anymore and by default it opens Recent, but it should either /storage or /storage/Download.

This is just Android file picker nonsense, on my device it automatically opens the last folder used, which is better than always going back to a specific folder, and from what I've seen it's not even possible to consistently set a default path to open.

It cripples the encoded .xml, check with Explorer or Root Explorer (Paid) by SpeedSoftware to see what I mean - it's nor actually readable after the edit, for that matter anything that can edit the Manifest "directly" does cripple it that way, being "APKTool M", Lucky Patcher or even NP Manager (I think, haven't used it previously) and I'm not sure about the old APK Editor Pro and the mods of it, but I don't remember it doing this, MT Manager on the other hand compiles/decompiles it probably always, being the string pool edit or the full edit one, but there are lines limit and it wants VIP for the unlimited edit (unfortunately), that's why I need your tool to work better.

All those tools (NP, Apktool M, LP, and my app) can view and edit manifest files from each other fine, the problem is with that Explorer app, and I can't do anything to solve it without the source code of it or MT Manager to figure out why it can't decode edited files unless they were done using MT.

[drogga]

I've fixed some typos in the OP, you can check if this changes some of your answers... ;)

In future, you can perhaps consider and implement a nice custom file explorer/picker, like the one in SAI (by Aefyr), which actually allows using either the built in one, or the system's, it's user's choice. The sorting preference for the app's one is in the settings there.

Regarding the crippled Manifest/XML > IDT, the problem is in Root/Explorer, I've discussed this years ago with the developer over multiple E-Mails, there's something with the formatting and it doesn't only read properly just files saved by MT Manager, but original/untouched or fully decompiled and recompiled packages as well, edited or not, IDK if you played with Root/Explorer and edited XML at all or enough, but I'm pretty sure that it's something with the AXML formatting and handling by all those apps that can quickly and dirty edit aXML, which it looks like only MT Manager does well and properly, basically anything else that can quickly modify/edit the Manifest - screws it (doesn't affect any system AFAIK, as such install and work), which doesn't prevent other apps from directly reading or editing it, so if anything - Root/Explorer at least shows me that something is edited in a quick/dirty/noob/bad way if i'm not sure and can't tell otherwise, honestly I don't even want the dev. of it to change how they are being read in order to show those properly and I haven't checked if other encoded XML(s) in a package are also crippled that way when edited without full package de/reCompile, or with anything other than MT (MT is awesome, but not perfect either, too bad it's expensive for my taste and I'm not a modder to make $ from monetized links to afford Lifetime VIP + MultiLogin to make it worth the purchase).

IDK if semi-direct editors of/for encoded .xml for other OS also cripple the Manifest, I don't use such (not that they are many), only used apktool for a while on Windows and Linux in the past, years ago.

[AbdurazaaqMohammed]

In future, you can perhaps consider and implement a nice custom file explorer/picker, like the one in SAI (by Aefyr), which actually allows using either the built in one, or the system's, it's user's choice. The sorting preference for the app's one is in the settings there.

SAI uses all files access permission, it's not possible to use custom file picker in newer versions of Android without granting it and this app doesn't need it, eventually I will make an patcher combining the features from my existing projects, which can actually justify having the permission.

Regarding the crippled Manifest/XML > IDT, the problem is in Root/Explorer, I've discussed this years ago with the developer over multiple E-Mails, there's something with the formatting and it doesn't only read properly just files saved by MT Manager, but original/untouched or fully decompiled and recompiled packages as well, edited or not, IDK if you played with Root/Explorer and edited XML at all or enough, but I'm pretty sure that it's something with the AXML formatting and handling by all those apps that can quickly and dirty edit aXML, which it looks like only MT Manager does well and properly, basically anything else that can quickly modify/edit the Manifest - screws it (doesn't affect any system AFAIK, as such install and work), which doesn't prevent other apps from directly reading or editing it

I forgot, MT decompiles the XML on a server. That's why it always needs internet and takes long. So I don't know what it uses to decompile and recompile it on the server. Also I tried arsclib/REAndroid APKEditor and it doesn't "cripple" it

Root/Explorer at least shows me that something is edited in a quick/dirty/noob/bad way if i'm not sure and can't tell otherwise

How exactly does paying for MT VIP or decompiling everything in apktool make it not any of those things?

[drogga]

IDK how well these ReAndroid's projects - APKEditor or ARSCLib .jar applets can work on and decode and encode back XMLs, because I've never tried them, I don't currently have Java installed on PC and I don't usually use things without a GUI or executables and I couldn't find any video on YT demonstrating the APKEditor, but I'm glad that it does it properly and I hope in future your projects also to be able to do it as well, if not better. I hope for the best ;), good luck and happy smooth coding.
Speaking of APK Editor, the old one by SteelWorks for Android with numerous of mods didn't seem to cripple the AndroidManifest.xml by editing it with any of the 3 methods (the 4th is just a file replacer) AFAIR.

How exactly does paying for MT VIP or decompiling everything in apktool make it not any of those things?

My English might not be native, but I believe it's pretty good and I've read this at least 3 times, but still couldn't comprehend the question here and I don't know how to answer to it, can you please rephrase it/elaborate ?, because of what I understood, my answer could only be - IDK.
I'm not a reverse engineer/modder, I know some things here and there, but that's about it, I can't read Java/Kotlin or Smali.

[AbdurazaaqMohammed]

You said "Root/Explorer at least shows me that something is edited in a quick/dirty/noob/bad way if i'm not sure and can't tell otherwise"

My question, since MT VIP will not show this, why is editing using those tools "quick/dirty/noob/bad" but MT VIP isn't?

[drogga]

It isn't, because it always saves readable by Explorer and everything else manifest on Android itself, unless previously crippled, then it won't fix it, or at least that was the case the last time I played around with this. Also MT has ID2Name with VIP. Any tool that can save readable as the untouched manifest is in my opinion a one that's worth using (if that makes any sense). I don't think I need to unnecessarily explain why exactly I used specifically the words dirty, noob and bad, I hope I didn't managed to somehow offend you, if I did, pls. forgive me, because that wasn't my intention.

BTW, the last update of the NP Manager claims to fix a critical bug in axml, let's hope is this one.

[AbdurazaaqMohammed]

Any tool that can save readable as the untouched manifest is in my opinion a one that's worth using (if that makes any sense).

No, it doesn't make any sense, there is no other app that has this problem, every other AXML decoder can read it fine, unless it somehow affects the performance of the app or something why would it matter.

Also MT did "fix" previously "crippled" files for me.

[drogga]

IDT we can consider the Viewer of Explorer exactly a decoder.
Good to know that MT fixes them for you, for me it doesn't (both string pool and decompile edit methods), I just rechecked again. IDK if you noticed, but the lines are re-arranged with different order when crippled and you decompile with MT to edit, compared to the non-crippled, the size is also less, so other tools for Android definitely f-up the encoding. I played around with APKTool M's Quick Edit & the direct Android Manifest lines editor - both f-up the manifest.

If you want, you can ofc. contact SpeedSoftware if you are certain that the problem is 100% there to get to the bottom of this, but I still don't believe its his app fault.

Bye for now. I hope you manage to push some update(s) ASAP to your editor to at least fix the more obvious things, like the text color, etc. Your "AntiSplit M" also needs a lot of work.

[AbdurazaaqMohammed]

The editor's text is black on a black background, so it's invisible by default, I had to change its color.
It asks to save decoded 2 times as a .txt file, while it can be as .xml so the syntax can perhaps work...?

I fixed these 2 issues.

About MT and the encoding, I believe MT actually does ID2Name by checking all ID references through byte approach, without decoding the XML, extract them from resources.arsc and put it in a new resources.arsc (To avoid uploading the whole resources) and uploads it to the server where it runs aapt or apktool.

I came to this conclusion becuase of how MT is the only app that can decode 2 kinds of obfuscated XML, Invalid chunk type 0 and EOFException (Those are the errors thrown by axml2xml).

Here is a sample of the first and second types for reference, the first is supposedly from Protect in ReAndroid APKEditor, and the 2nd one is from Modder Hub encryptor

axml2xml can't decode either, Apktool can decompile the 2nd but not the first, NP can only decompile the first, now MT is the interesting one, the string pool editor can edit both, but in the 2nd you will see a bunch of blank space at the beginning, because of how the length of fields were spoofed, but the full decompile works perfectly, so I believe it fixes the first error just like NP then uses apktool/aapt on the server. (Editing it by string pool will fix the first error, NP also fixes it)

Now since MT doesn't cause the "Crippling" of xml, I think it checks whatever changes you made and applies it by byte approach, both in string pool and full decompiler (Or maybe send it back to the server to recompile, idk).

the size is also less

I don't know whether you meant files edited by MT/apktool are smaller or the other tools are smaller, if the latter, this actually means all the other tools are superior, and we should actively strive to use xml2axml to compile instead of apktool, because saving even a single byte is more useful than keeping it readable by an app that no one would use to or even knew could decode AXML, and yes its a decoder, anything that converts AXML to human readable format is a decoder.

[drogga]

Thanks.
Lost Key: maybe use GH secrets in future to have a backup, even if you don't intend to use actions CI workflows.
Consider properly naming the assets in /releases, instead of the generic "app-release.apk" - less confusing to have app name with ver. when DLing, not having to rename during or afterwards ;)

The ID2Name theory thing would be valid if you have VIP and the option enabled and a resources.arsc to use in the first place and only in the Decompile method, so it can create a dummy temporary/working resources.arsc, it probably doesn't work that way with String Pool, without ID2Name and without resources.arsc to get the references from, like when editing external outside of package encoded .XML and nothing else is available to know the origin of or get any references whatsoever.

The fucked-up encoded .XML's are the ones with less file size (AFAIR) until fixed by a proper full package de/recompiling (apktool) and the size is not everything in this case, especially given the 2 examples by you and when it has to be as close to the source/original as possible and not crippled, relying on the decoder to handle/fix it to make it somewhat readable and properly syntaxed, this doesn't mean in any way that it's OK at all, thanks good that most systems don't mind and still install packages with such.
It sounds like you would apply unnecessarily compression and obfuscation with resources (incl. images) and dex confusion (known as minifyEnabled & shrinkResources when working with source), just to save up a few KB/MB's, me on the other hand - I prefer properly and fully purged junk, instead of any kind of compression methods and tactics.

[drogga]

AntiSplit M:
When the "Show dialog allowing selection of which splits to include" option is ON and I don't select any (nothing is selected by default) and proceed, a 0 bytes file is still being saved (the same if I Cancel), show a warning and refuse to proceed if/when nothing is selected or just make the OK button of the "Select APK files" greyed-out, ideally you can add an additional to the "Select All" option on top to select the base .apk and all the DPIs, since you mostly won't want to remove those (unlike additional languages than EN, ABIs or dynamic features), or base, all DPIs/ABIs and only EN to be selected by default. I think it might be unrealistic to expect you to be able to do what the installers like SAI & APKMirror do and the ones based on and for the current configuration to be selected.

System "Files" app and .xapk - AntiSplit M doesn't show up as available option in the "Open with" or "Share via", but it does for .apkm and others, along with other apps that can handle them, I think that this shouldn't be a system limitation, but I might be wrong.

Selecting splits that aren't in any archive is not possible with your app and archiving them to .zip also doesn't merge them, because it either doesn't list the splits or it says that it's searching for them and in both cases it always modifies the .zip file to an invalid 0 bytes on (that's really bad and is just and only because the extension is non other than ZIP).

java.io.FileNotFoundException: No '*.apk' files in directory: /storage/emulated/0/Android/data/com.abdurazaaqmohammed.AntiSplit/cacheb.b.c(SourceFile:190)b.a.h(SourceFile:6)com.abdurazaaqmohammed.AntiSplit.main.MainActivity.a(SourceFile:62)a.n.doInBackground(SourceFile:29)android.os.AsyncTask$2.call(AsyncTask.java:333)java.util.concurrent.FutureTask.run(FutureTask.java:266)android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)java.lang.Thread.run(Thread.java:764)
Searching apk files ...
File saved successfully

These 2 don't seem to make any difference in this case:
Ask where to save the file each time (if disabled, write the AntiSplitted APK to the same directory where the split file was from) & Show dialog allowing selection of which splits to include

[AbdurazaaqMohammed]

System "Files" app and .xapk - AntiSplit M doesn't show up as available option in the "Open with" or "Share via", but it does for .apkm and others, along with other apps that can handle them, I think that this shouldn't be a system limitation, but I might be wrong.

Can you check what MIME type are xapk files on your device? For me it is application/octet-stream (You can check it easily in Apktool M > click file > Details > More > Properties)

[drogga]

You can long-press > Properties, without going to Details > More first, but YES, the MIME Type is the same you see, perhaps you can exclusively add it to the manifest to support it, I've seen Video/Audio Players exclusively mentioning some known/common file extensions there (it includes lots of * per line)...

[drogga]

AXML Editor (1.7.0)
from the changelog: "Make the PopupMenu background black" - IDK which pop-up you mean (haven't invested much time to check), but the "Search attributes and edit" dialog is white.

...I somehow expected it now to look more like the AXMLPrinter (I haven't tried to build it with Actions and I don't have any IDE setup that I can use to build it locally), but this will probably increase the size or whatever and complicate the things for you...

[AbdurazaaqMohammed]

AXML Editor (1.7.0) from the changelog: "Make the PopupMenu background black" - IDK which pop-up you mean (haven't invested much time to check), but the "Search attributes and edit" dialog is white.

No I meant this menu this is a PopupMenu in Android

Now I themed the dialog too

...I somehow expected it now to look more like the AXMLPrinter (I haven't tried to build it with Actions and I don't have any IDE setup that I can use to build it locally), but this will probably increase the size or whatever and complicate the things for you...

I really don't understand what you are saying, if you didn't see AXMLPrinter app what were expecting it to look like