Set $JAVA_HOME and $ANDROID_SDK_ROOT on cmdline-tools package definition to avoid conflicts/impurities

[yangm97]

When running avdmanager from the flake template I get:

        java.lang.UnsupportedClassVersionError: com/android/sdklib/tool/AvdManagerCli has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

[yangm97]

Ok, this happens only if $JAVA_HOME is set. Shame on me.

[rabbitinspace]

happened to me with sdkmanager I would expect it to use java from nix as it's wrapped with JAVA_HOME set to a nix path

[yangm97]

The current wrapper has a weak preference for the java input used to build the package. It also expects $ANDROID_SDK_ROOT to be set by the user (instead of getting the path from nix).

https://github.com/tadfisher/android-nixpkgs/blob/d14d78067f5dc66a004900316e86f910264dc8a0/pkgs/android/cmdline-tools.nix#L10

I guess the ideal solution would be not to rely on these env vars but somehow allow consuming flakes to override the package definition to keep these customizable.

For the time being I'm working around this by running env -u JAVA_HOME avdmanager ....

[tadfisher]

Yeah, this is kind of a dilemma, because it can be useful to use cmdline-tools with non-Nix-managed SDKs and JDKs. Maybe exposing a passthru.unwrapped derivation could serve that use case, and we hardcode JAVA_HOME/ANDROID_SDK_ROOT in the wrapper to avoid impurities?

[rabbitinspace]

sounds like a solution to me but I guess this will be a breaking change