Android SDK Platform 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.
- Devel package for openSUSE:Factory
-
25
derived packages
- Links to openSUSE:Factory / android-tools
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout hardware/android-tools && cd $_ - Create Badge
Refresh
Refresh
Source Files (show unmerged sources)
| 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 |
Latest Revision
buildservice-autocommit
accepted
request 1160544
from
Paolo Panto (munix9)
(revision 61)
Paolo Panto (munix9)
(revision 61)
baserev update by copy to link target
Comments 25
[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.
I did the same for my dolphin-emu package, so I'm personally totally fine with this.
Can I convince you somehow to submit this to Factory again? :)
@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
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.
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
nope, it's still there https://build.opensuse.org/package/show/home:munix9/android-tools (the link above had additional garbage)
Ah, silly me :) lgtm
@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).
tar.xz files are also intelligible to wide range of tools
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).
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.
hm, I think openSUSE_Leap_15.2 needs the update-repo for gcc10
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?
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.
@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.
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.
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?
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.
The request sr#944118 was declined, not sure why.
Is it because the release is missing in the details of Provides/Obsoletes?
Because the rename is broken - see the decline message.
There isn't rename but package split which causes similar problems.
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
I know, I'm testing right now.
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")