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.