Package Details: android-sdk 26.1.1-2

Git Clone URL: https://aur.archlinux.org/android-sdk.git (read-only, click to copy)
Package Base: android-sdk
Description: Google Android SDK
Upstream URL: https://developer.android.com/studio/releases/sdk-tools.html
Keywords: android development
Licenses: custom
Submitter: None
Maintainer: dreamingincode
Last Packager: dreamingincode
Votes: 1479
Popularity: 0.33
First Submitted: 2007-11-12 19:26 (UTC)
Last Updated: 2022-03-22 20:58 (UTC)

Dependencies (22)

Sources (5)

Pinned Comments

dreamingincode commented on 2020-03-11 07:51 (UTC) (edited on 2020-03-11 08:50 (UTC) by dreamingincode)

@benedikt

cmdline-tools should be a different package because it's installed at android-sdk/cmdline-tools/latest, not android-sdk/tools of this package. They show up as different packages in Android Studio SDK manager as well, and they can be installed side-by-side.

Update: The new package has been published at https://aur.archlinux.org/packages/android-sdk-cmdline-tools-latest/

dreamingincode commented on 2017-04-18 11:40 (UTC) (edited on 2017-04-19 07:28 (UTC) by dreamingincode)

I'm going to update this package to 26.0.1 (it has been long-outdated), according to https://dl.google.com/android/repository/repository2-1.xml which is used by Android Studio. Some tools have been removed by upstream in this update (namely the standalone SDK Manager's GUI), and you may want to check against https://developer.android.com/studio/releases/sdk-tools.html for the breaking changes before this update. If you are using an AUR helper and you want to stay on the old version, consult your AUR helper's manual.

Latest Comments

« First ‹ Previous 1 .. 16 17 18 19 20 21 22 23 24 25 26 .. 44 Next › Last »

thestinger commented on 2014-03-03 15:29 (UTC)

You're not meant to use the `android` tool as a package manager with this package. There's no point of using this if you're going to let another package manager write over all of the files and add new untracked ones. This package will be updated when Google updates the <https://developer.android.com/sdk/index.html> page. If you're unwilling to wait, then just put the SDK in your home directory and use the included package manager and please don't flag it out-of-date before the new tarball is posted, unless you have a new source to suggest.

Zearan commented on 2014-03-03 14:34 (UTC)

Running `sudo -E` is the best recommendation in my eyes as it does exactly what you require ("preserve user environment when running command"). If it is not an option because you are too lazy to type it (I would be too), you can modify your /etc/sudoers to include ANDROID_SWT to 'env_keep' as described in: https://wiki.archlinux.org/index.php/sudo#Environment_variables A different approach without the need for a wrapper would be `sudo -i` to get a root login shell first and then run `android`.

ackalker commented on 2014-03-03 08:28 (UTC)

Just to be clear, `sudo -E android` is _not_ an option I would recommend (at least to me :) )

ackalker commented on 2014-03-03 08:26 (UTC)

On Arch x86_64, running `android` as root to update SDK components (yuck, bad software design choice, Google! But anyway...), I get the following error: $ sudo android SWT folder '/opt/android-sdk/tools/lib/run Java: parameters: -jar /opt/android-sdk/tools/lib/archquery.jar x86_64' does not exist. Please export ANDROID_SWT to point to the folder containing swt.jar for your platform. This is because `sudo` cleans out the environment before running the command, so variables like ANDROID_SWT (sourced from /etc/profile.d/android-sdk.sh) get lost. I'm proposing a wrapper (to put in user's $HOME/bin or in /usr/bin/android) containing: --[cut here]-- #!/bin/sh source /etc/profile.d/android-sdk.sh exec $ANDROID_HOME/tools/android "$@" --[cut here]-- Please consider including this in the package, or at least adding this workaround to the Wiki.

thestinger commented on 2014-01-20 06:26 (UTC)

Please don't use the out-of-date flag for anything but flagging a package out-of-date. Just leave a comment if something is wrong, rather than sending an extra email causing the maintainer to check for a new release upstream. > android-sdk W: Dependency included and not needed ('java-runtime') > android-sdk W: Dependency included and not needed ('lib32-alsa-lib') > android-sdk W: Dependency included and not needed ('lib32-openal') > android-sdk W: Dependency included and not needed ('lib32-libstdc++5') > android-sdk W: Dependency included and not needed ('lib32-libxv') > android-sdk W: Dependency included and not needed ('lib32-ncurses') > android-sdk W: Dependency included and not needed ('lib32-sdl') > android-sdk W: Dependency included and not needed ('swt') Namcap is just a lint tool and has many false positives and false negatives. It doesn't have the ability to figure out dependencies for Java. > is anybody maintaining this anymore? Yes. > among other things What other problems are there?

ILMostro7 commented on 2014-01-20 06:19 (UTC)

android-sdk W: Dependency included and not needed ('java-runtime') android-sdk W: Dependency included and not needed ('lib32-alsa-lib') android-sdk W: Dependency included and not needed ('lib32-openal') android-sdk W: Dependency included and not needed ('lib32-libstdc++5') android-sdk W: Dependency included and not needed ('lib32-libxv') android-sdk W: Dependency included and not needed ('lib32-ncurses') android-sdk W: Dependency included and not needed ('lib32-sdl') android-sdk W: Dependency included and not needed ('swt') among other things; is anybody maintaining this anymore?

synthead commented on 2013-12-07 00:47 (UTC)

android-sdk.desktop should have 644 permissions. Exec (in android-sdk.desktop) should contain /opt/android-sdk/tools/android in the event that the path /opt/android-sdk/tools is not in the user's environment.

ilpianista commented on 2013-11-04 08:01 (UTC)

Hi, no need to display the 'source /etc/profile' message on each update.

darkxsun commented on 2013-09-21 17:49 (UTC)

@donniezazen Remember that the Arch wiki is still a wiki---not everything there is a good idea, and certainly isn't any official recommendation. The procedure you followed allows the SDK's package manager to overwrite stuff pacman installed, and the wiki has an accuracy dispute tag in this section because it's generally considered bad practice.

donniezazen commented on 2013-09-21 16:15 (UTC)

@thestinger I am not clobbering the files/permissions with another package manager. I am using the installation method which is suggested by the Arch Linux Android wiki which suggests to change the owner. Thanks for replying.

« First ‹ Previous 1 .. 16 17 18 19 20 21 22 23 24 25 26 .. 44 Next › Last »