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.5.tar.xz 0019389824 18.5 MB
android-tools.changes 0000014824 14.5 KB
android-tools.spec 0000005079 4.96 KB
fix-install-completion.patch 0000002849 2.78 KB
man-pages.tar.gz 0000009420 9.2 KB
Comments 25

Paolo Panto's avatar

[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

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


Ludwig Nussel's avatar

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


Markus S's avatar

@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

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

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

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



Markus S's avatar

@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

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


Jan Zerebecki's avatar

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

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

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


Paolo Panto's avatar

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

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

@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

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

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

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

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

Because the rename is broken - see the decline message.


Michal Suchanek's avatar

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


Alexander Ahjolinna's avatar

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

I know, I'm testing right now.


Paolo Panto's avatar

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