Improve Android NDK path

[Skoti]

Description of feature/enhancement

It seems like ANDROID_NDK_HOME is no longer respected by Android Studio and sdkmanager as now there is only one path and it is ANDROID_SDK_ROOT which contains everything. NDK should be in the ndk-bundle subfolder.

There are only 2 ways to make it work:

1. Create a symlink in the current android-sdk installation folder i.e./usr/local/share/android-sdk/ndk-bundle pointing to /usr/local/share/android-ndk. This will make the current NDK installation to be used as a default for all projects.
2. Add ndk.dir=/usr/local/share/android-ndk in the local.properties file of an AndroidStudio project. This needs to be done for every project which uses android-ndk.

Would it be possible to either change the android-ndk installation path to /usr/local/share/android-sdk/ndk-bundle or change the caveat information to set ndk.dir instead of using ANDROID_NDK_HOME environment variable?

[reitermarkus]

Can you open a PR with your proposed changes? Might be easier to discuss that way.

[Skoti]

Hmm, I was hoping to discuss this first before I do anything.
Simply because I am not sure how the final implementation should look and also I am not familiar with homebrew code.

Changing caveat information is easy and at least it could guide people what to do, however, I think we can do better than this. So let's focus on the other idea.

I think it would be best to symlink the android-ndk installation into android-sdk/ndk-bundle.
I came up with two possible solutions:

• check in postflight of both casks if the other one is installed and if so symlink ndk as described above
• make android-ndk dependent on android-sdk so it can symlink almost without checks

Almost because in both solutions ndk might already be installed via sdkmanager - this means there is a conflicting folder ndk-bundle inside of android-sdk installation folder. Should we overwrite it with our symlink? Just print a warning message?

These are two ideas I have right now - which way should we go? If any at all, maybe you or someone else that have a better understanding of homebrew code can come up with a more suitable solution 😄

[reitermarkus]

I have so many questions.

Is sdkmanager part of android-sdk? What would you do if you installed the NDK manually? When would you need to do so? If you can install the NDK sdkmanager, would you ever need to install it manually? Is there a use case for the NDK without the SDK?

[Skoti]

Is sdkmanager part of android-sdk?

Yes it is. It is located at android-sdk/tools/bin. Tools folder is the only thing that downloads after running brew cask install android-sdk. The rest part of the sdk (i.e. platforms and build-tools) you install later depending on what you need either via sdkmanager directly or via its GUI in AndroidStudio (or other IDE) but they all are put inside android-sdk folder.

What would you do if you installed the NDK manually?

Well, you can always download it manually and put it in any convenient directory. It all comes down to providing ndk location either explicitly in command-line invocation or implicitly via environment variable or AndroidStudio or other IDE.

When would you need to do so? (install ndk manually)
If you can install the NDK via sdkmanager, would you ever need to install it manually?

I think only when you would like to use an older version of android-ndk. As currently sdkmanager does not support installing multiple ndk versions (although there is a ticket for it). Then if you're using AndroidStudio you need to specify the location of this older version via ndk.dir= in the local.properties file (to overwrite this default version from android-sdk/ndk-bundle). If you're using command-line then it is just specifying a path in a parameter.

Is there a use case for the NDK without the SDK?

android-ndk was designed as a companion toolset so it needs at lest the basic sdk tools.
I do not think android-ndk can be used totally independently.

Hope this helps 😃

[reitermarkus]

I think only when you would like to use an older version of android-ndk.

Since the cask is always at the latest version, does it even make sense to keep it at all, then?

[Skoti]

I think you're right - it is not necessary to have android-ndk cask.
After all, it is still available from android-sdk tools. In case anyone needs an older version they still need to handle it manually as sdkmanager does not yet support multiple ndk versions (as described above).

[reitermarkus]

Mind submitting a PR to remove the cask? Thanks.

[vitorgalvao]

Analytics:

android-ndk (added 675 days ago)
30 days: 1,021 (#113)
90 days: 2,518 (#123)
365 days: 4,934 (#127)

android-sdk (added 701 days ago)
30 days: 5,537 (#19)
90 days: 15,265 (#19)
365 days: 31,300 (#18)

I haven’t followed the conversation closely, but are we sure android-ndk isn’t necessary? Those are some high numbers. Granted, android-sdk’s are higher by a good margin, but it still doesn’t detract from the fact android-ndk is popular. And with such high numbers, I find it weird that nobody else has commented on a flaw with the cask, which makes me think we might be missing something.

[reitermarkus]

The same question I have asked here apparently has been asked before:

#31614 (comment)

And apparently the SDK automatically installs the NDK on-demand.

[Skoti]

@reitermarkus
Is the final decision to remove the ndk cask? 😄

[plastiv]

What if keep android-ndk for discoverability, but change its implementation to install android-sdk first and then make it run sdkmanager "ndk-bundle" "cmake;3.10.2.4988404" "lldb;3.1" as documentation suggests?
https://developer.android.com/ndk/guides#download-ndk

[vitorgalvao]

@plastiv That would make it an atypical (and weird) cask. Best not to follow that route, as it’d require bending over backwards,

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[sesam]

Mind submitting a PR to remove the cask? Thanks.

@reitermarkus you ask, and you receive: #59874

EDIT: On why people install cask android-ndk - they probably followed some reliable-looking blog post, and like me end up with an extra ~/Android/Sdk folder, and cask-installed Android Studio working fine, while things like starting an emulator from the command line fails. I'll now fix up my android paths as suggested above and shut up :)

[vitorgalvao]

Question: if we merge #59874, can this issue be closed as well (i.e. does its underlying problem get solved)?

[sesam]

I only know that I tried cask installing android-ndk by following some trustable-looking guide and it surprised me that it didn't work and had me experimenting with ~/Android/Sdk vs /usr/local/..... when the problem was really that I should've used the command line tool to download the NDK and delete my ~/Android folder completely instead.

Android Studio can update (maybe also create) a local.properties file and it adds the ndk path by itself, after being given a sdk path that contains the ndk-bundle as downloaded by the android command line tool as explained here above.

Above the idea to have the ndk package depend on the sdk package was dismissed.

The remaining alternatives seem to be

1. remove the android-ndk cask
2. experiment with symlinks
3. do nothing

(Now I'm off to manage my time better :impish-smile:)

[vitorgalvao]

Let’s remove the other cask and see what happens.

[MuntashirAkon]

@vitorgalvao you should at least add some message saying why this cask was removed and what is the alternative. Many people like myself are used to install android-ndk through Homebrew.

[vitorgalvao]

@MuntashirAkon There is a message. It’s this whole thread, which also includes the alternative.

Many people like myself are used to install android-ndk through Homebrew.

Then please tell us why! This whole thread is about the usefulness (or lack thereof) of that cask. We asked (in more than one place) and nobody answered. I know “many people” install the cask, I ran the numbers. What we need to know is why, and if android-sdk really is a suitable alternative.

If you want to comment on this change, I ask you to advance the discussion. Currently all we have to go on is one complaint (yours) for something that is easily reversible and we’re unsure of.

Make an argument for reinstating the cask, if that’s what you want to happen. Then the people who suggested this removal will be able to respond to it. HBC maintainers aren’t Android developers, we need the insights from the users of these casks to know how to deal with them.

[rcombs]

Thanks for reopening. As I explained in #65250, there are some use-cases for installing the NDK without the SDK when developing and testing native libraries for use on Android. In those use-cases, the cask is much easier to use than the SDK's built-in management system, so this seems like an excellent case for having a cask available.

My setup doesn't involve Android Studio or the ANDROID_NDK_HOME and ANDROID_SDK_ROOT env vars; I just need the toolchain, headers, and libraries the NDK provides (which I discover during local builds via ndk-which, symlinked by brew into /usr/local/bin).

[vitorgalvao]

@Skoti @sesam I’ve now marked the cask to be reintroduced, but I’ll give you some time to reply to @rcombs’ points before merging (or closing).

[sesam]

Reintroducing seems fine given above rationale.

Maybe the new ndk cask could show a post-install oneliner that it is suited primarily for use when you don't have the sdk, and via which-ndk

And if the ndk cask still is not compatible to have installed together with a sdk and/or ndk installed via other routes, and symlinks still off the table, how about also updating this ndk cask default paths to use the new standard paths?
And explain that. It forces old apps to start using the new paths (or just which-ndk), just like it would be if no ndk cask was available.

[Skoti]

@rcombs
android-sdk cask does not install any sdk at all, it just installs sdkmanager tool which you then use (directly through cli or via ide) to install particular android sdk versions or the ndk.

Yes it is. It is located at android-sdk/tools/bin. Tools folder is the only thing that downloads after running brew cask install android-sdk.

However, it is true that it needs some Java dependencies which is an additional step to configure it and it is unfortunate for you as you don't really need it.

So I guess we could reintroduce the ndk cask, but maybe as @sesam suggested with a short information that it's intended to use independently (when you're not using android-sdk cask).
Otherwise it will be confusing for the majority of people who use it in Android based projects - which is explained above in this thread and was the cause to remove the cask.

Or maybe we could merge the two casks into one? It will be named android-kit or still android-sdk to be backward compatible? This would install sdkmanager like android-sdk did, but it would also install a script.
The script would be described in cask post-install that it can be invoked to install the ndk (without a need to use sdkmanager) and it would install the ndk in a correct location like sdkmanager would install it. This way even if someone would use the script to install the ndk to use for Android development it would still work.
Although this approach would probably no longer support ndk-which command.

[vitorgalvao]

So I guess we could reintroduce the ndk cask, but maybe as @sesam suggested with a short information that it's intended to use independently (when you're not using android-sdk cask).

From “Homebrew Cask is not a discoverability service”:

users are expected to have reasonable knowledge about the apps they’re installing through us before doing so.

If a user doesn’t know the difference between the sdk and the ndk, it’s not our place to inform them.

Otherwise it will be confusing for the majority of people who use it in Android based projects - which is explained above in this thread and was the cause to remove the cask.

That confusion stems from the Android developers, not the casks themselves. It’s something that needs to be clarified upstream.

Or maybe we could merge the two casks into one? It will be named android-kit or still android-sdk to be backward compatible? This would install sdkmanager like android-sdk did, but it would also install a script. The script would be described in cask post-install that it can be invoked to install the ndk (without a need to use sdkmanager) and it would install the ndk in a correct location like sdkmanager would install it.

Making it a highly atypical cask with a heightened maintenance burden, with no one on the core team knowing how to deal with it.

Looks like the best bet is to reintroduce the ndk cask. It was popular and it seems like it still provides value. We’ll still be open to removing it in the future, but this needs to be less confusing.

Thank you everyone for the discussion.