Package Details: android-sdk-platform-tools 37.0.1-1

Git Clone URL: https://aur.archlinux.org/android-sdk-platform-tools.git (read-only, click to copy)
Package Base: android-sdk-platform-tools
Description: Platform-Tools for Google Android SDK (adb and fastboot)
Upstream URL: http://developer.android.com/sdk/index.html
Keywords: android development
Licenses: custom
Conflicts: adb
Provides: adb, android-tools
Submitter: Gordin
Maintainer: dreamingincode
Last Packager: dreamingincode
Votes: 1305
Popularity: 3.28
First Submitted: 2011-01-29 23:08 (UTC)
Last Updated: 2026-09-11 00:21 (UTC)

Required by (170)

Sources (4)

Latest Comments

1 2 3 4 5 6 .. 20 Next › Last »

dreamingincode commented on 2026-09-04 01:10 (UTC) (edited on 2026-09-04 01:51 (UTC) by dreamingincode)

I only saw one person (despite two comments) asking about PATH. That person has solved their problem so I didn't follow up on the PATH question.

I'm not sure if it's the recommended practice to symlink binaries in /opt/ to /use/bin. And in case if it is, it's still quite awkward to symlink for every binary inside this package and maintain that list of symlinks, compared to adding the directory to PATH and automatically make the binaries discoverable. And additionally this is also how all the other Android SDK AUR packages are doing it, so when I adopted this package I didn't want to change it, and right now I still prefer having consistency among these packages. There may also be existing users who relies on this setup in some way, e.g. having another package that installs /usr/bin/adb but not everything else in this package, and then they can use that adb but fall back to this package for other things, without a causing conflict in pacman.

So overall it's not a straightforward change and IMO not 100% beneficial, so I didn't bother discussing it with the previous commenter when their issue has been resolved.

mikelei commented on 2026-09-03 18:33 (UTC)

@dreamingincode I saw multiple people asked about this, but as the maintainer you didn't answer to any of them, so here I ask again: why did you put all binaries into /opt/android-sdk/platform-tools and use shell profiles to add the location into PATH instead of just use /usr/bin?

This has two problems:

  1. Not all users use bash/csh so they won't even have /opt/android-sdk/platform-tools in their PATH on shell startup.
  2. This package states that it provides android-tools, but not really because android-tools installs all binaries directly into /usr/bin.

dbacc commented on 2026-05-21 15:41 (UTC)

cp -a in package() segfaults inside fakeroot on ZFS due to a bug in libattr 2.5.2's attr_copy_file() (fixed upstream (https://github.com/sailfishos-mirror/attr/commit/58abfe6) but not released). Even with the fix, cp -a still errors out with "No data available" because it tries to preserve xattrs that don't translate across the fakeroot boundary on ZFS.

Fix: replace cp -a with cp -r --no-preserve=ownership since there's no reason to preserve xattrs on downloaded SDK binaries:

Fuechslein commented on 2026-02-08 16:09 (UTC)

Using adb wait-for-device with this package causes mouse input freezes every few seconds that only stop after killing the process manually. Just using CTRL+C is not enough.Problem doesn't exist with the platform-tools package.

dreamingincode commented on 2025-05-03 04:03 (UTC) (edited on 2025-05-03 04:04 (UTC) by dreamingincode)

This package follows the stable channel (channel 0) from Android SDK Manager in Android Studio, whose source can be found at https://dl.google.com/android/repository/repository2-1.xml . So there might be delay if you only look at the release notes at https://developer.android.com/tools/releases/platform-tools .

dreamingincode commented on 2025-02-03 18:29 (UTC)

This one is packaging prebuilt platform tools from Google and is the one usually used by Android Studio users. android-tools builds from source instead. Both are valid choices imo.

vitaliikuzhdin commented on 2025-02-03 10:48 (UTC)

Just found android-tools. So why does this package even exist?

vitaliikuzhdin commented on 2025-02-03 10:39 (UTC)

@dreamingincode, you are correct, thank you for pointing that out. However, the current method is still a bad practice and does not work for every shell. Symlinking will solve the PATH issues once and for all.

dreamingincode commented on 2025-02-03 01:42 (UTC) (edited on 2025-02-03 01:43 (UTC) by dreamingincode)

I don't think adb is supposed to require root to run - or could you please link to an official source for that?

Or maybe you need to install the android-udev package and make sure you are in the adbusers group? https://wiki.archlinux.org/title/Android_Debug_Bridge#Daemon_exits_with_insufficient_permissions_error

vitaliikuzhdin commented on 2025-02-02 22:21 (UTC)

Is there a reason why the package modifies the PATH for some selected shells instead of simply symlinking the binaries to /usr/bin/? Since newer versions require elevated permissions to work, it becomes frustrating to have to use sudo $(which adb).

1 2 3 4 5 6 .. 20 Next › Last »