Support for relative tool paths

[kefir500]

Support for relative tool paths

[kefir500]

Test support added in 770636e.
I will run more checks to make sure this feature works fine.
You can download the latest development build here.
Let me know if it works.

[kefir500]

I mean, did you redownload it after this message?

[tumatanquang]

Okay, I tried reloading later, the relative path seems to work, when I tried typing ./tools/demo.jks in the Keystore path field and then hit OK, the tool didn't update path to the absolute path, hope it works fine in the release.
I'm waiting for it to be released! 😄

[kefir500]

Thank you for your suggestions.

UTF-8 filenames

Please, provide the following information:

1. An example filename
2. Your operating system

ADB update

Since the SDK platform tools are downloaded on the pre-build phase using the download script, the APK Editor Studio builds should contain the latest ADB version available at the time of the release.

Relative paths

The ./ notation does work, however it refers to the current working directory which can be different from the application executable directory. The feature you mentioned could be really helpful with portable builds. I'll see what I can do, thanks for the idea.

File compression

APK Editor Studio delegates the build process to the Apktool, so all (un)packing options are inherited from this third-party tool. I'm not familiar with APK Editor Pro, however my first guess is that it is using the ZIP compression which makes it possible to select different compression ratios.

[tumatanquang]

Thank you for your suggestions.

UTF-8 filenames

Please, provide the following information:

1. An example filename
2. Your operating system

ADB update

Since the SDK platform tools are downloaded on the pre-build phase using the download script, the APK Editor Studio builds should contain the latest ADB version available at the time of the release.

Relative paths

The ./ notation does work, however it refers to the current working directory which can be different from the application executable directory. The feature you mentioned could be really helpful with portable builds. I'll see what I can do, thanks for the idea.

File compression

APK Editor Studio delegates the build process to the Apktool, so all (un)packing options are inherited from this third-party tool. I'm not familiar with APK Editor Pro, however my first guess is that it is using the ZIP compression which makes it possible to select different compression ratios.

UTF-8 filenames:

1. Example: Trình duyệt Via.apk opening that file on the app will get an error because the file cannot be found, the file name displayed on the app is Tr?nh duy?t Via.apk but if I change the name to Via.apk, it opens normally.
2. Operating system: Windows.

ADB update:

I'm not sure, but I use the ADB download here: https://dl.google.com/android/repository/platform-tools-latest-windows.zip
Everything is working properly.

Relative paths:

I am very grateful to you for that.

File compression:

APK Editor Pro tool on Android can choose the compression level from 0 (uncompressed) - 9 (super-compressed). Whereas WinRAR has only 5 compression levels. I don't know exactly how the APK Editor Pro tool uses to compress but its compression is very good (but also uses a lot of the phone's CPU and Battery when using compression level 9). If you improve the compression capabilities of the software, fine. If not, then no problem!

[tumatanquang]

Alternatively, if you can edit the Decompile source code (smali) function into a menu bar option after opening the APK file, one-click to instantly decompile the source code of the open APK file, instead of having to go to Settings, activate Decompile source code (smali) and reopen the APK file, at this point decompile source code (which is quite inconvenient).
That would be great!

[kefir500]

UTF-8 filenames

Seems that the Java CLI doesn't properly support non-ASCII arguments on Windows, and APK Editor Studio relies heavily on Java (due to the Apktool dependency).

ADB update

Yes, the same URL is used in the script referenced in my previous message :)

File compression

As I mentioned before, APK Editor Studio is using Apktool under the hood. That means that the major repacking options are controlled by this third-party tool. Apktool, in its turn, is using Android AAPT for building which does not support different compression levels as far as I know.

Source decompilation

Again, since APK Editor Studio delegates the unpacking functions to the Apktool, the source decompilation should be enabled on the initial unpacking step, therefore the repeated repacking is required anyway.

Separate issues

Also, please create separate issues (for each bug / feature / question) in future since it's much easier to track, tag and triage them in this way.

[tumatanquang]

It seems the biggest hurdle here is Java because this software depends a lot on it. It beat most of my requests.
I'm just looking forward to relative paths for the portable version on the next version.
Set the label for this issue to Feature.
Thanks.

[tumatanquang]

Test support added in 770636e.
I will run more checks to make sure this feature works fine.
You can download the latest development build here.
Let me know if it works.

I downloaded it and tried the relative path feature test. The file I use: apk-editor-studio_win32_dev.zip
When I use the drive D: the path is: D:/APK Editor Studio/tools/mykey.jks
I tried moving the folder APK Editor Studio to drive C: and check, the path I got was: C:/APK Editor Studio/tools/mykey.jks
However, the Keystore path located in the config.ini file at Drive letter:\APK Editor Studio\data\config is still saved as Drive letter:/APK Editor Studio/tools/mykey.jks instead of ./tools/mykey.jks or tools/mykey.jks.
Everything is quite perfect, hope when officially released, the above problem has been fixed: On the tool can still display full Drive letter:/APK Editor Studio/tools/mykey.jks but in the file config.ini keep the path is ./tools/mykey.jks or tools/mykey.jks.
Also, I hope the release will support storing Keystore password and Key password in config.ini files so that I don't have to rewrite them every time I use them (maybe as options, it's up to everyone's preference. want to save or not, encrypt them or not, does not matter).
P/s: I haven't tried signing the app yet because my app hasn't been updated to the new version yet. Hence, I still don't know if it really works or not. 😅

[kefir500]

• You should specify a relative path in the "Keystore path" field. Also, the b44ead3 commit contains a minor fix for this input field.
• Currently the ability to save passwords is powered by platform-specific managers, which is considered relatively safe and reliable way to store secret data. The ability to store passwords (encrypted or not) in a config file creates a serious security breach even as an optional feature.

[tumatanquang]

• You should specify a relative path in the "Keystore path" field. Also, the b44ead3 commit contains a minor fix for this input field.
• Currently the ability to save passwords is powered by platform-specific managers, which is considered relatively safe and reliable way to store secret data. The ability to store passwords (encrypted or not) in a config file creates a serious security breach even as an optional feature.

I tried specifying a relative path to ./tools/demo.jks and then hit "OK". But the tool automatically updates the path to Drive letter:/APK Editor Studio/tools/demo.jks in the "Keystore path" field. I think should use something like replace ./ to Drive letter:/APK Editor Studio/ when displayed and when saving to the config file replace Drive letter:/APK Editor Studio/ to ./.

[kefir500]

Did you try the latest build?

But the tool automatically updates the path "Keystore path" field

Actually, it should save the proper relative path. There was a minor bug: when you reopen the Key Manager dialog, the field value is reset to an absolute path. This issue was fixed in the commit mentioned in my previous message :)

[tumatanquang]

Did you try the latest build?

But the tool automatically updates the path "Keystore path" field

Actually, it should save the proper relative path. There was a minor bug: when you reopen the Key Manager dialog, the field value is reset to an absolute path. This issue was fixed in the commit mentioned in my previous message :)

Yes, I use the development version from the link you sent above. When I opened the key manager dialog and pressed OK, the software automatically updated the relative path to the absolute path.
I think there is a workaround to this problem, instead of pressing OK will immediately update the path, do a check if the Keystore path field has been changed by the user and the keystore file exists or not?
If the path is changed and the keystore file exists, then update the new path, if the path does not change and the keystore file exists then ignore it.