Android SDK Platform Tools

Edit Package android-tools
https://github.com/nmeum/android-tools

Android SDK Platform Tools is a component for the Android SDK. It includes tools that interface with the Android platform, such as adb, fastboot, and systrace. These tools are required for Android app development. They're also needed if you want to unlock your device bootloader and flash it with a new system image.

Although some new features in these tools are available only for recent versions of Android, the tools are backward compatible, so you need only one version of the SDK Platform Tools.

Refresh
Refresh
Source Files (show merged sources derived from linked package)
Filename Size Changed
android-tools-34.0.4.tar.xz 0019287700 18.4 MB
android-tools.changes 0000013351 13 KB
android-tools.spec 0000004960 4.84 KB
fix-install-completion.patch 0000002849 2.78 KB
man-pages.tar.gz 0000009420 9.2 KB
Comments 25

Paolo Panto's avatar

munix9 wrote

[regarding to http://bugzilla.opensuse.org/show_bug.cgi?id=1156268]

I have moved the udev-rules to the new package 'android-udev-rules' (similar to arch), and the required group is managed by the package 'system-group-adbusers'.

See the changes in https://build.opensuse.org/package/show/home:munix9/android-udev-rules and https://build.opensuse.org/package/show/home:munix9/android-tools

Let me know what you think, I need to test it a little more under TW/15.1.


Markus S's avatar

KAMiKAZOW wrote

I did the same for my dolphin-emu package, so I'm personally totally fine with this.


Ludwig Nussel's avatar

lnussel wrote

Can I convince you somehow to submit this to Factory again? :)


Markus S's avatar

KAMiKAZOW wrote

@lnussel Wouldn't this involve creating the obscpio files locally and then uploading them via osc? Personally, I'm not interested doing this every few weeks for over 400MB. Can't speak for @munix9


Paolo Panto's avatar

munix9 wrote

One solution might be to limit the size of the sources to the minimum necessary for compilation. I changed this for testing (https://build.opensuse.org/package/show/home:munix9/android-tools): - obs_scm => tar_scm - mode="disabled" - many "include" parameters

Locally an "osc service disabledrun" and upload of the new/changed files is then sufficient.

But I don't know if this is flexible enough for maintenance. It is only tested on TW.


Ludwig Nussel's avatar

lnussel wrote

Ah, sorry I didn't see the notification here now your branch is gone :(

If bandwidth is an issue I guess we could find a solution by using a jumphost in the opensuse network or running a bot that updates the sources.

Also pushing the OBS guys to finally do something about https://github.com/openSUSE/open-build-service/issues/2110 might help


Paolo Panto's avatar

munix9 wrote

nope, it's still there https://build.opensuse.org/package/show/home:munix9/android-tools (the link above had additional garbage)


Ludwig Nussel's avatar

lnussel wrote

Ah, silly me :) lgtm


Markus S's avatar

KAMiKAZOW wrote

@munix9 @lnussel tar_scm is deprecated and openSUSE devs don't want it because they claim that obscpio files are smaller (not once I could confirm that – they've always been bigger than tar.xz files).

Btw, another reason besides the file size is that I actually use the web interface, not osc. Sometimes I just change a few lines in the _service file from my phone on the go (it'd kinda my substitute to playing Ballz).


Michal Suchanek's avatar

michals wrote

tar.xz files are also intelligible to wide range of tools


Jan Zerebecki's avatar

jzerebecki wrote

Another solution is to submit to an intermediary package name like android-tools-merged-sources, then send a POST request to /source/<project>/<package>?cmd=mergeservice , then submit the result to Factory. To make it easier to create the request you can make a static html file with a button that sends it (it is not CSRF protected, so that should work).


Paolo Panto's avatar

munix9 wrote

This is a possible candidate for inclusion of the package in Factory/TW:
https://build.opensuse.org/package/show/home:munix9:test/android-tools

Discussion should better take place here:
https://bugzilla.opensuse.org/show_bug.cgi?id=1185883

I'm still waiting for gcc11 as default in Factory and https://github.com/nmeum/android-tools/pull/29

Let me know what you guys think about it.


Paolo Panto's avatar

munix9 wrote

hm, I think openSUSE_Leap_15.2 needs the update-repo for gcc10


Paolo Panto's avatar

munix9 wrote

I think there was some confusion about this package now.
The intention behind it was and is that users would have liked to see it in Factory and possibly later in Leap.
The biggest problem was that the sources are unfortunately not available as an archive, so the detour via the Github repo nmeum/android-tools was created.
To be able to complete the whole thing now, the following would probably still have to be done:
- rename the package from android-tools to android-platform-tools (see https://build.opensuse.org/request/show/908580 )
- minor adjustments to the _service file, so that "go_modules" works (again)
- repeated attempt to bring it into Factory
What do you think about this?
Did I forget anything else?


Markus S's avatar

KAMiKAZOW wrote

I think the distribution reviewers did a bad job at reviewing when demanding the new name because nmeum's project is called "android-tools", meaning the package name is now factually wrong. It it were up to me (it isn't), I'd revert the whole renaming thing.


Yavor Uzunov's avatar

Yav wrote

@KAMiKAZOW I also wondered how the package should be renamed. Maybe create a new package with the exact same content but with a different name and delete this one.


Markus S's avatar

KAMiKAZOW wrote

I'm not a maintainer of the hardware repo, so I cannot do it. I'm not sure it even needs to be renamed here and not just named "android-platform-tools" when submitting the package to Factory.


Petr Vorel's avatar

pevik wrote

I'm not sure, but it'd be better to name it the same in hardware and in Factory. I'm a hardware maintainer, just not yet that much experienced thus I let more experienced maintainer to raise renaming issue, I'm sorry for that, sorry for wasting your time. But as I later I check (and wrote in some of previous PR) that name is common in other distros and adding "platform" does not help much (upstream repo is https://android.googlesource.com/platform/system/core, thus package name is missing core and system. I'd would like to finish this effort (endup this silly agony). Can't we just accept some of the previous efforts which was correct? https://build.opensuse.org/request/show/908079 has a correct name. Or could you please submit yet another PR (some of the old ones) which has correct name and I'll accept it?


Markus S's avatar

KAMiKAZOW wrote

Our upstream is https://github.com/nmeum/android-tools/ not the googlesource one and our upstream doesn't have "platform" anywhere it its name (probably because it's not a full platform SDK, only the actual CLI tools). As I said, I'm personally in favor of reverting to the "android-tools" name but I don't have time to argue with distro reviewers who don't review very well. If you happen to have time to discuss this with Namtrac, I'd be grateful. Should you be willing to talk to him and he still insists to add -platform to the name, I won't stand in the way either even though the name is wrong.


Paolo Panto's avatar

munix9 wrote

The request sr#944118 was declined, not sure why.
Is it because the release is missing in the details of Provides/Obsoletes?


Michal Suchanek's avatar

michals wrote

Because the rename is broken - see the decline message.


Michal Suchanek's avatar

michals wrote

There isn't rename but package split which causes similar problems.


Alexander Ahjolinna's avatar

ahjolinna wrote

https://github.com/nmeum/android-tools/releases/tag/33.0.3p1 Fixed mkbootimg (see #78) Added avbtool (see #79) Fix for compatibility with Linux >= 6.0 (see #74) Removal of several obsolete patches


Paolo Panto's avatar

munix9 wrote

I know, I'm testing right now.


Paolo Panto's avatar

munix9 wrote

I am preparing version 34.0.4.

Is there interest in a version for ppc64le?

Only the program "e2fsdroid" must be excluded, because it cannot be compiled for ppc64le.
Just let me know.

(Bundled boringssl doesn't support the big endian architectures, eg. "ppc ppc64 s390x")

openSUSE Build Service is sponsored by