apkeditor: init at 1.4.1

[UlyssesZh]

APKEditor: Powerful android apk resources editor.

This package installs a command APKEditor.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Atemu]

Diff LGTM

[Atemu]

Given that we have a from-source version, do you think there's merit in the precompiled version?

[UlyssesZh]

The pre-compiled version is different from the from-source version in that it uses the binary libraries in the repo while the from-source version compiles those binary libraries from their original source. I cannot know what is the version of the libraries that the pre-compiled release use, so one of them may have bugs that the other one does not have.

[SuperSandro2000]

Yeah? Almost any software we are packaging in nixpkgs is not using the exact version of all dependencies as upstream does but usually that is not that big of a deal especially if it is just a patch or a minor release.

one of them may have bugs that the other one does not have.

Is that theoretical or did the from source compiled version actually not work as expected in your tests?

[Atemu]

This is starting to look pretty good.

One thing that sticks out a bit is that the file is quite long. Would it be possible to factor out the vendored deps into separate files perhaps?

[Atemu]

Some final nits.

I have ran the binary and it successfully decompiles an APK.

[Atemu]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 349470

---

x86_64-linux

✅ 2 packages built:

• apkeditor
• apkeditor-bin

[Atemu]

Could you split the package inits into separate commits? Then we can merge.

[SuperSandro2000]

Before we merge, I want to take another look at #349470 (comment) because I think if the source variant is buggy, we should not package it and if it isn't then we don't need the binary variant. If theoretical something could not work but in practice it does, I think we should drop the binary package.

[UlyssesZh]

It's theoretical. I see your point. Normally I won't package with the binary if I can build from source.

APKEditor manages its dependencies by having the dependencies compiled as jar files in the libs dir instead of letting Gradle fetch from Maven or something. This untypical way of managing dependencies made me re-thought about this. Normally, if building from source with different version of dependency doesn't work, we can know which difference caused this because we can see the codes. For APKEditor, it would be harder to troubleshoot in this case because we technically cannot see the source codes of its dependencies.

I do not know what people would do in this case by convention. I briefly tested the package built from source, and it worked, so if you think we can delete the package built from binary, I am OK with that.

[Atemu]

Yeah let's skip the binary package for now.

[Atemu]

gradle_6 was dropped yesterday: #352490. You'll have to make it work with gradle_7 or newer.