Edit Package android-tools

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.

Refresh
Refresh
Source Files (show merged sources derived from linked package)
Filename Size Changed
_service 0000000263 263 Bytes about 1 year
android-tools-31.0.3p1.tar.xz 0025760004 24.6 MB 6 months
android-tools.changes 0000009300 9.08 KB 8 days
android-tools.spec 0000005288 5.16 KB 8 days
fix-add-e2fsprogs-contrib.patch 0000001365 1.33 KB 6 months
fix-add-functional-include.patch 0000000238 238 Bytes about 2 months
fix-install-completion.patch 0000002785 2.72 KB 12 months
vendor.tar.gz 0001280712 1.22 MB 6 months
Comments 22

Paolo Panto's avatar

munix9 wrote over 2 years ago

[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 over 2 years ago

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


Ludwig Nussel's avatar

lnussel wrote over 2 years ago

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


Markus S's avatar

KAMiKAZOW wrote over 2 years ago

@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 over 2 years ago

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 over 2 years ago

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 over 2 years ago

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 over 2 years ago

Ah, silly me :) lgtm


Markus S's avatar

KAMiKAZOW wrote over 2 years ago

@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 almost 2 years ago

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


Jan Zerebecki's avatar

jzerebecki wrote about 2 years ago

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 about 1 year ago

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 12 months ago

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


Paolo Panto's avatar

munix9 wrote 11 months ago

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 11 months ago

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 11 months ago

@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 11 months ago

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 11 months ago

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 11 months ago

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 6 months ago

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 6 months ago

Because the rename is broken - see the decline message.


Michal Suchanek's avatar

michals wrote 6 months ago

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

openSUSE Build Service is sponsored by