Hi, thanks reporting this.

Unsure if this is related to a "Secure Level" in MSEC tool.

This is legitimate. But, installing a program is done as root user with urpmi.
Adding first user with default ID 1000 to usb group is beyond the scope of a installer. Perhaps, changing udev rule like your above question 1 is possible. But, it is a administrator level to add an existing user to a group, not by a automated tool like urpmi.

Assigning to registered maintainer.

Assignee: bugsquad => geiger.david68210
CC: (none) => ouaurelien

@Alex; thanks for reporting, and the tips!

I have noted the system during boot do look for the 'plugdev' group:

$ sudo journalctl -b | grep android
apr 30 14:16:36 svarten.tribun systemd-udevd[954]: /usr/lib/udev/rules.d/51-android.rules:8302 Unknown group 'plugdev', ignoring

So maybe another solution is to add that group.

Summary: Access to your smartphone via ADB (no permissions) => Access to your smartphone via ADB (user permissions)
CC: (none) => fri

Hi, Aurelien and Morgan. Aurelien, thank you for the detailed explanation about the "usb" group, now I will know. Morgan, there is indeed one "raw" position in the file /usr/lib/udev/rules.d/51-android.rules that contains a reference to the "plugdev" group (what she's doing there is unclear): 

# Fuzhou Rockchip Electronics
SUBSYSTEM=="usb", ATTR{idVendor}=="2207", MODE="0666", GROUP="plugdev"

Probably, some guy tried to fasten his device and changed it to himself 'idVendor' on 'Rockchip' chips: https://www.rock-chips.com/a/en/products/index.html According to the latest news, which I haven't checked, users of Debian-distributions have no problems editing the rules, they simply add the user to "plugdev": https://developer.android.com/studio/run/device.html

For the sake of interest, I opened the deb-package from Ubuntu 21.04:  
http://archive.ubuntu.com/ubuntu/pool/universe/a/android-sdk-meta/android-sdk-platform-tools-common_28.0.2+3_all.deb

There in the file /usr/lib/udev/rules.d/51-android.rules:
...
#Intel
SUBSYSTEM=="usb", ATTR{idVendor}=="8087", ATTR{idProduct}=="09ef", ENV{adb_user}="yes"
...
#Enable device as a user device if found
ENV{adb_user}=="yes", MODE="0660", GROUP="plugdev", TAG+="uaccess"
...

Thank you for your participation in solving the problem. :)

With respect,
Alex

Continuing the topic...

From the "51-android.rules" files from Mageia-8 and from Ubuntu-21.04, I put together one. Now, after replacing the native file /usr/lib/udev/rules.d/51-android.rules and rebooting (or command: udevadm control --reload-rules && udevadm trigger), the phone is recognized even without being included in the "usb" group. I'll leave it here just in case (see attachment)...

An additional bonus - "adb" stopped automatically starting after a reboot. I remember spending 2 days trying to figure out where it starts from, since autorun via systemd was in "disable".

The file turned out to be "magic", since I have little idea of the principle of operation of this entire farm. However, it works for me. I hope David GEIGER doesn't beat me up too much for this. :)

Sincerely,
Alex

Created attachment 12695 [details]
51-android.rules

Created attachment 12696 [details]
screenshot of my super program :)

Thanks Alex Kotov for your work on this complicated android-tools package :)

So on Cauldron I switched to the Unoffical CMake-based build system for android command line utilities at https://github.com/nmeum/android-tools with latest 31.0.0p1 release.

I also used your modified 51-android.rules file.

I renamed fastboot-android to originally fastboot.

But for now it does not build on Cauldron due to some issue with new gcc 11 :(


Also is it possible to use an official 51-android.rules file at https://github.com/M0Rf30/android-udev-rules without modified it to see if it still work? 

thanks in advance!

So for tests I first backport android-tools 31.0.0p1 in 8/Core/Backports_testing!

When all will be good I will do an official update for Mageia 8.

Finally I managed to build it successful on Cauldron :)

(In reply to David GEIGER from comment #9)
> Finally I managed to build it successful on Cauldron :)
Hello, David. Congratulations on this wonderful event.
android-tool - is a very cool thing. Thank you for doing this. :)

I downloaded and installed a new "android-tools": https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/core/backports_testing/android-tools-31.0.0p1-1.mga8.x86_64.rpm

> adb version
Android Debug Bridge version 1.0.41
Version 31.0.0p1-android-tools

So far, I have tested it on emulators (tcpip) vv5.1/9.0 from https://osdn.net/projects/android-x86/releases

Restarting and shutting down the device is not performed correctly. Namely, after shutdown (adb shell reboot -p) or reboot (adb reboot), "adb devices" shows that the device is still connected and working. The reboot and shutdown sequence must pass through the "device offline" stage, and this status is absent or not monitored. :(

Meanwhile, the previous version of android-tools handled the "offline" status correctly and the device disappeared from the active connections of the adb server after 1-2 minutes. The new version informs about disabled devices that they are still in a working state.

I haven't reached the USB connection yet. However, I am sure that the result will be the same, since the emulators quite accurately simulate a real device.

David, is it possible to fix the "offline" status and correct disconnection of disabled devices from the server in the new version of android-tools?

p.s. I hope that by that time my wife will return my smartphone for further testing... :)

Sincerely,
Alex

(In reply to Alex Kotov from comment #10)
> 
> David, is it possible to fix the "offline" status and correct disconnection
> of disabled devices from the server in the new version of android-tools?


Do not know how to do that :(

Maybe asking here: https://github.com/nmeum/android-tools/issues

David, I decided to keep you company and additionally wrote my question to the upstream. If you have free time, join us. :)

With respect,
Alex

*** Bug 28876 has been marked as a duplicate of this bug. ***

CC: (none) => lovaren

(In reply to David GEIGER from comment #11)
> Maybe asking here: https://github.com/nmeum/android-tools/issues
Hi, David.
An update is likely to follow soon android-tools:
https://github.com/nmeum/android-tools/issues/28

With respect,
Alex

David, I additionally inform you that the recommended rules file is https://github.com/M0Rf30/android-udev-rules (not changed) like the previous one - both work. The "ZTE" smartphone is recognized without manipulating users and groups in Mageia. It remains to wait for the update of the android-tools version to 31.0.2 and it will be possible to collect everything in a package. In any case, which of the rule files to use is up to you. I am sure that the final package of android-tools will be very good. :)

Remark for the rules file https://github.com/M0Rf30/android-udev-rules

Is required:
---
su/password
groupadd adbusers; gpasswd -a $LOGNAME adbusers

Based on the output of the "journalctl-b | grep android" command, you need to include the user in the "adbusers" group. Although it works for me without manipulating users and groups, this may affect the search for other smartphone models, since these rules use the "GOTO" operator and some branching.

p.s. that's all for now... :)

Hi, David.

The author has released patches and updates platform-tools-31.0.2...

Sent update request: https://github.com/nmeum/android-tools/issues/28
Update to platform-tools-31.0.2: https://github.com/nmeum/android-tools/pull/29

The author writes: "No idea what this is about, if anyone has a better idea on how to fix this. Let me know."

Corrected version: https://github.com/nmeum/android-tools/tree/platform-tools-31.0.2

David, if you have the time, could you see what exactly is presented there and whether it is possible to build a package from it?

Thank you in advance,
Alex :)

Hi, David. I continue to keep you up to date with developments regarding android-tools-31.0.2. On my question (the "offline" status when the device is turned off/reboot), the author has already made corrections and now android-tools is perfectly assembled and works, at least for me. I took the liberty of using the "android-tools.spec" from your package and built rpm android-tools-31.0.2-0 exclusively for testing before the author (nmeum) releases the official release. I temporarily placed the packages on my android-tools fork, where they are available for testing to everyone. I really hope I didn't do anything illegal, since the packet prefix doesn't use "mga". They are located in the folder "RPM-for-testing": https://github.com/AKotov-dev/android-tools/tree/platform-tools-31.0.2 When the official release of v31.0.2 will be released, the author has not yet announced, and I will inform you about it later.

With best wishes,
Alex

Сontinuation testing android-tools v31.0.2 until the official release...

Hello, David. Taking advantage of the fact that I have 3 free days after the vaccination from Covid-19, I decided to make a "vaccination" and for the package "android-tools" v31.0.2 taking into account all the latest changes from the author (nmeum) and taking into account the latest messages from forum users (Bug 29157 - Morgan Leijström). :)

I do this so as not to lose sight of anything and not to lose it at the moment when you start releasing the official package, as well as for yourself and general testing...

To date, a list of common changes and differences between the official package "android-tools-10.0.0_r2-3.mga8" and what we are testing here (v31.0.2) is reflected in "android-tools.spec":

%changelog
* Sat Jun 26 2021 AKotov-dev <alex_q_2000> 31.0.2-0.mrx8
- new version: 31.0.2 (testing only)
- fixed "TCP keep alive" https://github.com/nmeum/android-tools/issues/28
- fixed "mke2fs location" (Thanks to Morgan Leijström, mga#29157)
- add android-tools LICENSE

* Tue May 04 2021 daviddavid <daviddavid> 31.0.0p1-1.mga8
+ Revision: 1721285
- new version: 31.0.0p1
- switch to the unoffical CMake-based build system project for android command
  line utilities at https://github.com/nmeum/android-tools
- fix 51-android.rules file to make it usable with user
  permissions (Thanks to Alex Kotov, mga#28860)
- rename fastboot-android to fastboot like it is originally (mga#24139)
- branch android-tools in backports repo

URL for download v31.0.2: https://github.com/AKotov-dev/android-tools-rpm

After installation:
---
su/password
usermod -aG usb $LOGNAME; reboot

With respect,
Alex

Hi Alex
Thank you for your work :)

1)

Mageia android-tools use to provide /usr/bin/fastboot-android 
But your package provide /usr/bin/fastboot

On Mageia this android fastboot utility use to be renamed fastboot-android because package lsb-core-noarch provides /usr/sbin/fastboot, which is a utility that immediately reboots the system.

I dont like it as i have accidentaly rebooted my computer almost every time i wanted to use the android fastboot... and so have others
 Bug 24139 - Rename fastboot-android into just fastboot
I guess we should decide on that bug about name.
Is Mageia the only distro that renames android fastboot?
I guess we can not rename lsb-core-noarch /usr/sbin/fastboot to remain compliant?
Now having both installed, issuing "fastboot" makes the computer reboot, i have to issue /usr/bin/fastboot for the android one.


2) 

Installed per your instruction, reboot.
For me neither
 /usr/bin/fastboot devices
nor
 adb devices
give result issued as root or as user.
I have tweaked some file in order for it to work on my phone some time ago, this time i did not care, I am out of time for now.

Does it work for you?

Hi, Morgan.

Yes, the ZTE smartphone is recognized without problems for me.

I suggest starting with the point №2... :) First, we will connect the smartphone from under the user, and then we will see how fastboot behaves.

If your phone is not in the lists of rules, I suggest that we all decide on the choice of the rules file: /usr/lib/udev/rules.d/51-android.rules. Earlier, David GEIGER suggested considering another option, namely: https://github.com/M0Rf30/android-udev-rules/blob/master/51-android.rules

If this file contains idVendor/idProduct your smartphone There is nothing difficult in replacing one file with another in the package. This rule file requires the user to be included in the "adbusers" group, the creation of which is also not a problem at the package installation stage.

Could you clarify whether this file contains https://github.com/M0Rf30/android-udev-rules/blob/master/51-android.rules idVendor/idProduct Your smartphone?

For example (smartphone is connected):
> lsusb
lsusb Bus 002 Device 103: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II]

Result: idVendor=04e8, idProduct=6860

p.s. Thank you for your participation in building the package...

@Morgan Leijström
Additionally, if you have free time, you can try to find out your "idVendor" and add it to the existing list of rules via the "ArEditor" GUI: https://github.com/AKotov-dev/areditor

Sincerely,
Alex

That editor is a nice initiative, Alex :)
Will try that later.

But there must be some smarter way of doing this than users having to edit a file for almost every phone...

Maybe make a small script that runs lsusb, list its findings (automatically excluding what it can identify as hubs, keyboard, mouse, touchpad, printers, etc) ... and ask user which is the phone and from that create a minimalist rules files just for that phone?

In the 51-android.rules file line 22..25 some universal method is referenced but i do not understand and that URI is not working.

---

Following is research made now and then during the day, before i saw your post about the editor.

Once i figured put how to get each phone into fastboot mode, fastboot works.
(and i have uninstalled the LSB fastboot to avoid rebooting host...) ;)
Also, the Jolla provided shell script for loading sailfish on my phone worked flawlessly.

adb devices never worked for any, will try later with edited rules file.

So i guess fastboot do not use the rules file.
And the ID to enter is only the one lsusb show when phone is running normally?
Funnily it seem dependant on phone OS, not just phone!  (see XA2 below)

_______________________________


Fairphone 3, main phone, switched to /e/ q (andriod10): 
Booted normally, not in 51-android.rules:
  ID 18d1:4ee1 Google Inc. Nexus/Pixel Device (MTP)
neither adb nor fastboot find it

Booted to fastboot mode, in list as "Generic and unspecified debug interface":
  ID 18d1:d00d Google Inc. Xiaomi Mi/Redmi 2 (fastboot)
$ /usr/bin/fastboot devices
A209K1NW0202    fastboot        -- hooray yes works as normal user! :)

---

Fairphone 2, original OS: (plan to switch it to /e/ or sailfish)
Booted normally, not in 51-android.rules:
  ID 05c6:f006 Qualcomm, Inc.
Off, charging:
  ID 2ae5:f000 Fairphone B.V. 2 (Mass storage)
Fastboot mode:
  ID 18d1:d00d Google Inc. Xiaomi Mi/Redmi 2 (fastboot)
$ /usr/bin/fastboot devices
8504b6b4        fastboot
$ /usr/bin/fastboot reboot
Rebooting                                          OKAY [  0.000s]
Finished. Total time: 0.201s

---

Sony Ericsson Xperia XA2 Dual SIM H4113
   * Today i loaded it with Sailfish as i wrote this post! * :)
Booted normally into ORIGINAL OS, not in 51-android.rules:
  ID 0fce:01f7 Sony Ericsson Mobile Communications AB H4113
Booted to some kind of fastboot mode, dim *green* LED:
  ID 0fce:b00b Sony Ericsson Mobile Communications AB Android
$ /usr/bin/fastboot devices
????????????    XFL
No idea what that was but I succeeded entering root unlock key...
$ adb devices
(finds none)
Booted to another fastboot mode, dim *blue* LED:
  ID 0fce:0dde Sony Ericsson Mobile Communications AB Android
CQ3000J44G      fastboot
  (I read there is also a third mode when LED is supposed to be red)
Booted into Sailfish:
  ID 0fce:0afe Sony Ericsson Mobile Communications AB Xperia XA2 - Dual SIM
neither adb nor fastboot find it
Off, charging
  ID 0fce:0afe Sony Ericsson Mobile Communications AB Xperia XA2 Dual (AOSP)
  (same ID but slight change in description)

Note: i got different second part of ID when booted with original OS compared to Sailfish 4 (including Sony binaries v16)

Sidenote: Some variants of this phone is tricky to get in fastboot mode: https://forum.xda-developers.com/t/unable-to-get-xa2-in-fastboot-mode.3860119/ but point 6 here worked on my variant: https://jolla.com/sailfishx-linux-instructions-xa2/

(In reply to Alex Kotov from comment #0)

> edit /usr/lib/udev/rules.d/51-android.rules

this ia _always_ the wrong advise  to give, as it _will_ be overwritten on udev updates.

if you want to override / add udev info..

copy /usr/lib/udev/rules.d/51-android.rules to /etc/udev/rules.d/51-android.rules and edit that one

that way your changes will not be overwritten

Hi, Morgan.
Yes, I need to distract myself somehow (regarding ArEditor) while I have the weekend off. :) For some reason, Morgan, you have a lot of cool smartphones and all are different. ;) I think that's why their "idVendor" is not yet in the rules lists, they do not have time to make them. I don't have a smartphone myself (it's not safe in Russia), so I take my wife's smartphone for experiments (it's not always possible to take it away). She has a Chinese ZTE of the 2016 sample (almost wooden and works everywhere and in any variants, of course "with the participation of a hammer"). Your experiments were very informative. Please let me know if there is any more useful information. Thank you in advance...

Sincerely,
Alex

Hello, Thomas Backlund.

Thank you very much for your valuable advice. :) This radically changes everything, by the way... That is, it turns out that in our "android-tools" package, the file 51-android.rules must be immediately moved to /etc/udev/rules.d/51-android.rules, so that nothing happens to it when updating other packages (except android-tools). This is amazing! I'll have to work with the android-tools package and the rules editor so that the latter searches for them in two places, starting with /etc/udev/rules.d/51-android.rules.

Thomas, suppose we have two files 51-android.rules with different content: /usr/lib/udev/rules.d/51-android.rules and /etc/udev/rules.d/51-android.rules. If this happens, how will they "overlap" each other? Who is more important (priority)?

Sincerely,
Alex

(In reply to Alex Kotov from comment #26)
> Hello, Thomas Backlund.
> 
> Thank you very much for your valuable advice. :) This radically changes
> everything, by the way... That is, it turns out that in our "android-tools"
> package, the file 51-android.rules must be immediately moved to
> /etc/udev/rules.d/51-android.rules, so that nothing happens to it when
> updating other packages (except android-tools).

Sorry, I typoed when I wrote "udev updates"...
I meant "package updates", in this case android-tools (as that file belongs there)

>  This is amazing! I'll have
> to work with the android-tools package and the rules editor so that the
> latter searches for them in two places, starting with
> /etc/udev/rules.d/51-android.rules.
> 
> Thomas, suppose we have two files 51-android.rules with different content:
> /usr/lib/udev/rules.d/51-android.rules and
> /etc/udev/rules.d/51-android.rules. If this happens, how will they "overlap"
> each other? Who is more important (priority)?


the one in /etc/udev/rules.d will always override the one in /usr/lib/udev/rules.d/ if they have the same name.

this is by design so sysadmin can override configs as shipped by packages.

@Thomas Backlund
I think I got it. This means that the file 51-android.rules from the android-tools package will in any case be placed along the old path: /usr/lib/udev/rules.d/51-android.rules and will be overwritten (possibly with newer and more complete contents) with each new version/release. But if I want to add rules that will be taken into account in any case, even after reinstalling android-tools, then I fix the copy in /etc/udev/rules.d/51-android.rules. This is of course more convenient, so that you don't have to fix it again every time. Thank you again. :)

____51-android.rules location

Yes areditor could 
1) offer top copy the default /usr/lib/udev/rules.d/51-android.rules to /etc/udev/rules.d/
  (and if it does not exits, demand it)
2) always edit /etc/udev/rules.d/51-android.rules

- Preferrably with some comment about priority.


____AREDITOR

$ sudo urpmi areditor-0.3-0.mrx8.x86_64.rpm

Feedback: GUI Buttons "Default" and "Apply" have only top millimetre visible, so no text visible.  Luckily i can see at github what they are, and click them.  Plasma, 4K screen.

Areditor say Fairphone 3 and XA2 need no addition.

  Added:
#Fairphone2
SUBSYSTEM=="usb", ATTR{idVendor}=="2ae5", ENV{adb_user}="yes"


____adbusers group!

(In reply to Alex Kotov from comment #21)
> This rule file
> requires the user to be included in the "adbusers" group

OOPS that is what i was missing!
I now created that group and added myself there.
Would be nice if adb or something had warned...
I guess next version of package will create that group (if we still use a rules file that need it), but user have to add himself too.
Anyhow maybe you can integrate that check (and maybe check for other criterias) into areditor ?


____TESTING

Connecting to Fairphone 3 OK:   Proves this package is working :)
$ adb devices
List of devices attached
A209K1NW0202    device

---

Fairphone 2:  I believe it is not set up to accept adb (USB debugging)... Have not used it for a while until today, and as it is slanted for reflashing i have forgotten the login... to be reflashed to /e/ soon... to update status here later...

---

Xperia XA2: Sailfish, which i today put on it, do not have adb...
Can be installed - but too much work for me for now.


____Best of things

(In reply to Alex Kotov from comment #25)
> For some reason, Morgan, you have a lot of cool smartphones
> and all are different. ;)

I use to select what i use with care.
So i end up with all the best things like... Mageia :)

(OK my old Mercedes lorry do not look like it is best in class except if you count rust...  But it is the inside that counts :) )

Hi, Morgan.
From what you wrote about smartphones and Mercedes, I realized that you are a true connoisseur of quality and beauty, and this is wonderful. :)) As you correctly noticed, the content is important, not the appearance, I completely agree with this. :) Thank you very much for the tests you conducted. Conclusion: something is already working. :) Now I have a dilemma - which of the 51-android.rules files to use as the main one: the one that is already in the package by default (from Fedora), or the new one from here https://github.com/M0Rf30/android-udev-rules/blob/master/51-android.rules ? The native file is undoubtedly larger in size and clearly contains more records about the equipment, but it is not updated by anyone (?). And the second one has a host/upstream, which, in theory, is engaged in its modernization/replenishment, but the list of "Issue" on GitHub is empty (?) and this is doubtful. The first file has a more or less clear "flat" structure and it is not difficult to add a rule to the general list, at the same time, the second file has a more complex format and it will be difficult for an ordinary user to add something there. I wanted to consult with you, as a person who often deals with smartphones, which of the files would you recommend to put in a package?

Additionally, I would like to inform you that ArEditor has also updated it taking into account almost all the recommendations (the list of changes in the release description v0.4). If there is trouble with the display of the buttons again, then please post a screenshot from your Plasma (4K). Do you use non-standard scaling? Just in case, I uploaded a new screenshot from the Plasma virtual machine to GitHub (I use Budgie myself). Link: https://github.com/AKotov-dev/areditor

Sincerely,
Alex

First: Finishing the test of Fairphone 2: OK! :)
Used fastboot to load TWRP,
Booted recovery mode to TWRP -> adb devices and sideload works :)
Installed /e/, enabled developer mode, enabled ADB -> adb devices works :)

( /e/ (will be renamed soon) = https://e.foundation/ ) 

Yes this is really working - many thanks for your efforts!

As you say decision is needed on which rules file to ship
And from there decide about adbusers group.

---

For the rules file, i seem to me that the complicated one is meant to be more general and not needing as much adding of devices, especially convenient for future devices.

In case it fail, can users use ArEditor to add to that file reliably?
Maybe describe an exact position in that file where to put the code, or let ArEditor paste there automatically?

Best is probably to reach out to some Android forums and ask people who really are into this about which file, or some other, is best as base.

---

I am getting the hang on the reflashing procedures now.
However i am *not* very experienced with flashing or adb.
I just decided to run Sailfish and /e/ and went head in.

---

Will try new ArEditor later - i see no rpm there yet?
Anyways, gotta work now, party tonight, and finish an apple packaging machine tomorrow (special build of cirquit board to replace old broken one from the eighties)

@Alex, ArEditor details, from screenshot and readme:

a) When something else than a phone is selected in top field, the middle field say device is already in list.  A bit confusing!  As it seem you already have the logic, it could instead say something like "Not a phone" instead.'
("Already in list" displayed only for a selected phone that is in list)

b) Somewhere text should tell user to copy /usr/lib/udev/rules.d/51-android.rules to /etc/udev/rules.d/  Or do the button "Default" do that?  Anyhow it is to be worked, that should be described.

(In reply to Morgan Leijström from comment #32)
> @Alex, ArEditor details, from screenshot and readme:
> 
Why "screenshot"? There's a Release v0.4: https://github.com/AKotov-dev/areditor/releases I just decided to fix all our actions a little... :)

> a) When something else than a phone is selected in top field, the middle
> field say device is already in list.  A bit confusing!  As it seem you
> already have the logic, it could instead say something like "Not a phone"
> instead.'
And if it's a phone? And it can also be an Android tablet, a USB flash drive, etc.? 

> ("Already in list" displayed only for a selected phone that is in list)
There are not only smartphones in the lists. idVendor is registered there, and the vendor produces everything: flash drives, smartphones, and more. Here, too, you need to think... At least the old rules file operates with idVendor.

> b) Somewhere text should tell user to copy
> /usr/lib/udev/rules.d/51-android.rules to /etc/udev/rules.d/  Or do the
> button "Default" do that?  Anyhow it is to be worked, that should be
> described.

Morgan, based on your deep testing (Comment 31) I think that the most rational option is to use a new rules file + create a group of "adbusers". The package has already worked with the old file, now let it work with the new one. :) I'll start assembling it soon... As they say - "Come what may".:) I have a few more questions later for you, if you don't mind...

@Morgan
By joint efforts, the final test package android-tools v31.0.2 built: https://github.com/AKotov-dev/android-tools-rpm I did not change the version and release of the package, it remained so 31.0.2-0, in order not to overlap with the official release, which is managed by David GEIGER. So if this version is already installed, then "dnf -y reinstall android-tools-31.0.2-0.mrx8.x86_64.rpm". Now you need to add the user to the group "adbusers".

Morgan, in your (Comment 29) Did you add a rule:
Added:
#Fairphone2
SUBSYSTEM=="usb", ATTR{idVendor}=="2ae5", ENV{adb_user}="yes"

And in (Comment 31) You have successfully tested this smartphone. At the same time, you added the above lines already to a new file from https://github.com/M0Rf30/android-udev-rules/blob/master/51-android.rules ??? That is, does he also understand this format?

I took a look at the format of individual records that walk through this file and are valid, for example:
#YU
ATTR{idVendor}=="1ebf", ENV{adb_user}="yes"
#ZUK
ATTR{idVendor}=="2b4c", ENV{adb_user}="yes"
и так далее...

I think that ArEditor can be taught to insert the right lines in the right place. For example, above the lines at the end of the file:
# Skip other vendor tests
LABEL="android_usb_rule_match"

+ 1 an empty string for the following inserts... Then the user will only click the button. I will think about this + I need to not forget "About" with thanks to all the participants of this interesting discussion. It is a pity that the weekend on the occasion of my vaccination is over and most likely I will go to Moscow tomorrow. However, I sincerely hope for the continuation of our interesting dialogue, Morgan. Your testing and participation very important and useful.

Sincerely,
Alex

Created attachment 12823 [details]
ArEditor 0.4 screenshot, two buttons mostly hidden

___ArEditor 0.4
I was looking at https://github.com/AKotov-dev/areditor
expecting a link somewhere to releases but i cant see one...?
Thanks for the direct link.

---

New version show slightly more of the buttons, but not OK, see attached screenshot.
I have not (to my memory) tweaked any graphics settings from default, and i have no other program showing this issue.

---

I see ArEditor 0.4 filters out the hubs, good.
Now I only see phones and Cordless mouse listed in top section.
It also filters out the keyboard, i dont know it is good or bad, as it do not filter out the mouse...?
Anyhow not important for our use case.
In screenshot you also see lsusb output to compare.
This is with my Fairphone 2 plugged in, booted /e/

---

Fairphone: 
As you see in the screenshot, My Fairphone 2 now show another ID than before ??

Anyway the rules included in your new android tools package know about Fairphone:

$ cat /usr/lib/udev/rules.d/51-android.rules | grep air
#       Fairphone 1 (see Hisense 109b)
#       Fairphone 2 (f005=tether, f00e=rndis, 90de=charge, 90dc=charge,adb f000=MTP, 9039=MTP,adb, 904d=PTP, 904e=PTP,adb, 9015=storage,adb, 9024=rndis,adb) 90bb=qualcom midi+adb
ATTR{idVendor}!="2ae5", GOTO="not_Fairphone2"
LABEL="not_Fairphone2"
#       Hisense (includes Fairphone 1)
#               Zopo ZP900, Fairphone


And it works without modification :) for my Fairphone 2
$ adb devices
List of devices attached
8504b6b4        device


Fairphone 3 is also detected without altering
$ adb devices
List of devices attached
A209K1NW0202    unauthorized

"unauthorized" i also got for Fairphone 2 until i granted the access in the phone. Fairphone 2 asked in dialogue, Fairphone3 i had to disable and enable for it to ask me to grant new key, and now it connects OK.

New key, why? Because the updated adb package or because i issued
 $ adb kill-server; rm -rf ~/.android/*; adb start-server
  ?
Maybe try to avoid regenerating the key?
I do not know what is normal here.

---

Suggestion: if not too hard, add a search function to help users navigate the rules file.
Example: Right now i was hunting for the goto labels...

Hello, Morgan.
In general, I decided to focus ArEditor on the average user and made automatic insertion of rules if the device is not in the lists. From the GUI, the user will not be able to edit anything manually, however, he will be able to observe the insertion of ready-made rules. And the rules themselves are inserted with one "+" button and immediately applied. In other words, so that the user does not spoil anything. :) Spoil/fix a file /etc/udev/rules.d/51-android.rules allowed ArEditor only. :) In this version (v0.5), I tried to take into account the scaling factor in your Plasma (4К).

ArEditor repository: https://github.com/AKotov-dev/areditor
Repository Releases: https://github.com/AKotov-dev/areditor/releases

At the same time, I fixed the scaling in adbmanager.

Morgan, what do You think, if just create a specific rule file 51-android.rules, which will contain idVendor== from 0000 to FFFF... Won't this eliminate the need to ever add new usb devices at all? After all, in this way we expand the general range of vendors and even those that do not even exist. Then, in theory, will no longer have to search for a new rule file or add something. Or is this already "fanaticism"? :)

Created attachment 12831 [details]
Screenshot of ArEditor 0.5 : OK

Looks nice on my screen.

I also note my mouse is no longer listed.

In screenshot, my Fairphone 2 and Sony XA2 are connected.

ArEditor thinks both are not in list, but they are both working with adb without editing the file.  I have no idea to solve that, partly because the rules are not a simple list, partly because the phones change ID depending on mode (but only the last part)

Basically user should try using adb before altering rules file.

I have not tested letting it change the file.
What is the minus button supposed to do?


About rules to accept everything, I have no idea how adb knows what device is a phone.  What may happen if it tries to communicate with i.e my advanced mouse that have configuration settings and something accidentaly got written?

I think you should discuss with an android developer forum.

Anecdote: In the nineties i had an expensive CAD program with hardware key dongle inline with the printer on the parallel port.  One day the key had been destroyed - apparently by some printing commands that happened to alter the key...  Got it refreshed, but only after a couple weeks stop in CAD work, sending in the dongle...

Please check https://bugs.mageia.org/show_bug.cgi?id=24139#c10
Can that idea be implemented in android-tools?

When user runs fastboot it will be the android one.
Launched by root, computer reboots.

(In reply to Alex Kotov from comment #36)

> Morgan, what do You think, if just create a specific rule file
> 51-android.rules, which will contain idVendor== from 0000 to FFFF... Won't
> this eliminate the need to ever add new usb devices at all? After all, in
> this way we expand the general range of vendors and even those that do not
> even exist. Then, in theory, will no longer have to search for a new rule
> file or add something. Or is this already "fanaticism"? :)

Bad idea.

it will make udev trigger on a  lot of devices, causing a cascade of errors that will screw up end-users systems.

(In reply to Thomas Backlund from comment #39)
> Bad idea.
> 
> it will make udev trigger on a  lot of devices, causing a cascade of errors
> that will screw up end-users systems.
Hi, Thomas. It's all my curiosity that's to blame. Now I understand. Thank you. :)

(In reply to Morgan Leijström from comment #37)
> Created attachment 12831 [details]
> Screenshot of ArEditor 0.5 : OK
> 
> Looks nice on my screen.
> 
> I also note my mouse is no longer listed.
> 
> In screenshot, my Fairphone 2 and Sony XA2 are connected.
> 
> ArEditor thinks both are not in list, but they are both working with adb
> without editing the file.  I have no idea to solve that, partly because the
> rules are not a simple list, partly because the phones change ID depending
> on mode (but only the last part)

Morgan, I forgot about the fact that you need to search for vendor matches in a new format, sorry. :) Fixed it: https://github.com/AKotov-dev/areditor/releases/tag/v0.6

> Basically user should try using adb before altering rules file.
> 
> I have not tested letting it change the file.
> What is the minus button supposed to do?
The "minus" button is a reset to default...

> 
> Anecdote: In the nineties i had an expensive CAD program with hardware key
> dongle inline with the printer on the parallel port.  One day the key had
> been destroyed - apparently by some printing commands that happened to alter
> the key...  Got it refreshed, but only after a couple weeks stop in CAD
> work, sending in the dongle...

LPT keys, like everything that was connected to LPT, was an achievement for its time. :)

(In reply to Alex Kotov from comment #41)
> (In reply to Morgan Leijström from comment #37)

> Morgan, I forgot about the fact that you need to search for vendor matches
> in a new format, sorry. :) Fixed it:
> https://github.com/AKotov-dev/areditor/releases/tag/v0.6

Great, thats good now :)
For all my three phones in this thread plus a Galaxy A3.6 i get:
 "The device is already in the list of rules. No action is needed."

And i like the new buttons, but:

> The "minus" button is a reset to default...

Minus to me mean subtract the current rule in section 2)...

Maybe instead of minus: D for Default and text below field 2):
 "Button (+) adds the rule above to the rules below.
 "Button (D) loads the default rules /usr/lib/udev/rules.d/51-android.rules"

(Would be logically better if the load default button was adjacent to field 3) but i guess the layout is problematic to realise elegantly.)

And i would like to rewrite description for section 3 to:
 "3) This program writes the rules below to /etc/udev/rules.d/51-android.rules"


I suggest a help (?) button left of the (i) button, that pops up a short description what this program do and how to use it.


--- OT ---

> > Anecdote: 
...
> 
> LPT keys, like everything that was connected to LPT, was an achievement for
> its time. :)

Well the hardware dongles was one of the things that pushed me to libre software...  Even more so when i was in machine room in middle of atlantic to fix a problem in a PLC, and Win98 in the laptop borked during download to machine.  Had to struggle to move the PLC editor software key file from a half working OS to another laptop with half broken screen while captain was watching the dead boiler control panel, and me sweating...

LPT port was wonderful. Actually used it in two projects last millenium using BASIC and signalling to an external microcontroller for the realtime but very simple stuff.  My first product was an I/O port for LPT, a compact good looking box with screw connections and LEDs. This was while i was still in highscool, and sold about hundredfifty ones to other highscools and univeristy.

For field 3 maybe three buttons

Load default - /usr/lib/udev/rules.d/51-android.rules
Load saved   - /etc/udev/rules.d/51-android.rules
Save         - /etc/udev/rules.d/51-android.rules

On program launch load saved if it exist, else default.
On exit either autosave, dont save, or ask. Watever - just it is written somewhere which it does.

Its about taste, and how to handle more than one phone not in default list.

Hi, Morgan. I reread your wishes regarding the interface and upgraded some things, but not everything. With all due respect, I find such information content and the number of buttons superfluous for such functionality. A real user, like most of us, needs only one big red button with the inscription "Jackpot". :) However, thank you for the recommendations. The final ArEditor version (v0.7) is here: https://github.com/AKotov-dev/areditor/releases

Sincerely,
Alex

Looks good to me.
Lets see that jackpot button in next version :)

Minor grammar issue, for post final version ;) :

 Rule to insertion or a hint:

   ->

 Rule to insert, or a hint:

(In reply to Morgan Leijström from comment #45)
> Looks good to me.
> Lets see that jackpot button in next version :)
> 
> Minor grammar issue, for post final version ;) :
> 
>  Rule to insertion or a hint:
> 
>    ->
> 
>  Rule to insert, or a hint:
Thank you, fixed (same release). I have such a translator here. He even translates the word "Button" as "Пуговица" (Pugovica) (this is what is sewn to clothes in order to fasten it). It is impossible to sew a button from a doorbell to a shirt, this is not correct. Just as it is impossible to tear off the "Button" from the clothes and replace the button in the call with it. :)

Morgan, if there are still any inaccuracies in ArEditor, if it would not be difficult for you, please let us know. Thank you in advance...

(In reply to Morgan Leijström from comment #20)
> Hi Alex
> Thank you for your work :)
> 
> 1)
> 
> Mageia android-tools use to provide /usr/bin/fastboot-android 
> But your package provide /usr/bin/fastboot
> 
> On Mageia this android fastboot utility use to be renamed fastboot-android
> because package lsb-core-noarch provides /usr/sbin/fastboot, which is a
> utility that immediately reboots the system.
> 
> I dont like it as i have accidentaly rebooted my computer almost every time
> i wanted to use the android fastboot... and so have others
>  Bug 24139 - Rename fastboot-android into just fastboot
> I guess we should decide on that bug about name.
> Is Mageia the only distro that renames android fastboot?
> I guess we can not rename lsb-core-noarch /usr/sbin/fastboot to remain
> compliant?
> Now having both installed, issuing "fastboot" makes the computer reboot, i
> have to issue /usr/bin/fastboot for the android one.

It looks like this to me, Morgan...

#Under the User
[marsik@localhost ~]$ fastboot --version
fastboot version 31.0.2-android-tools
Installed as /usr/bin/fastboot

[marsik@localhost ~]$ fastboot reboot
< waiting for any device >

#Under the root
[marsik@localhost ~]$ su -
Password: 
[root@localhost ~]# fastboot
...goes to reboot...

You don't work with devices under root anymore, do you? Or do you need root specifically?

Sincerely,
Alex

You are right:
With this update users do not need to be root for neither fastboot nor adb  :)

So i think we may just close 
  https://bugs.mageia.org/show_bug.cgi?id=24139
with a comment like that, and work to release this update

About Areditor: include it as a package, suggested by android-tools?

(In reply to Morgan Leijström from comment #48)
>...
> About Areditor: include it as a package, suggested by android-tools?
Hi, Morgan.
Since I have difficulties understanding the translation again, I will describe both situations. :)

The "adb" package (Requires: adb) is written in the dependencies of the "arceditor" package, since the 51-android.rules file from the "android-tools" package is required for "arceditor".

The reverse situation...

There is no binding to the "arceditor" package in the "android-tools" dependencies, since "arceditor" is unofficial. The android-tools package is made on the basis of spec from David GEIGER and I have no right to change the required dependencies, except, for example, "BuildRequires", without which it could not be built. I think David GEIGER has already prepared a big baseball bat for me for arbitrariness. And the fact that he hasn't come for a long time, to be honest, bothers me. :)

Optional information:
---
The method of building the package "arceditor" = "portable rpm" - is an odd average between "snap" or "flatpack" and rpmbuild. In the packages of my own programs that I release, the compilation process is carried out outside of spec, since I, as a developer, do it manually in real time (Lazarus). If I created a spec according to all the rules (as professional maintainers do), then it would take 2 months to release the program, taking into account free time. Therefore, the spec in my programs is the simplest list of files packed in the rpm-format (with rpmbuild) using its "RPMCreator" program, which, in parallel, if you take into account the same names of dependencies, can also collect "deb" packages. Anyone can easily build an rpm package from any files already located in the right places of the system: https://github.com/AKotov-dev/RPMCreator for personal use or quick publication. But this is another topic.

Kind regards,
Alex

@Morgan
"areditor" - the typo above, sorry. This translator is making itself felt again, Morgan. By the way, since there were no more comments, the final version was released after all (v1.0): https://github.com/AKotov-dev/areditor/releases 
Definitely, it is always necessary to bring the matter to its logical conclusion. Thank you again for your exceptional, personal approach and in-depth testing.

Sincerely,
Alex

OK :)
Waiting for David G.

*** Bug 27414 has been marked as a duplicate of this bug. ***

*** Bug 26474 has been marked as a duplicate of this bug. ***

Hello, Morgan.

How are you doing in sunny Sweden? We have a very hot, atypical weather for Russia +35 degrees of heat in the Moscow region for a month now. People bathe in fountains - the only salvation in the open space in the town. :)

While the official android-tools-31.0.2 in the upstream has not yet been released (the author is "nmeum" testing something there), I continue testing android-tools and am looking for additional applications for it. :)

Since you like different things for smartphones, I also have this - Droidcam: https://www.dev47apps.com

Perhaps you or someone else will be interested in playing with this thing in your free time... :)

I recently put together several Droidcam client rpm-packages and they work:
URL: https://github.com/AKotov-dev/droidcam-rpm

Droidcam packages (x86_64):
---
dkms-v4l2loopback_dc-0.0.1-3.mrx8.noarch.rpm
droidcam-cli-1.7.3-1.mrx8.x86_64.rpm
droidcam-1.7.3-1.mrx8.x86_64.rpm

...they need to be installed and reboot the computer to raise the necessary kernel modules

Remark: If you don't need it anymore, you can delete everything installed above like this: urpme --auto dkms-v4l2loopback_dc

How it works:
---
A small DroidCam server (better install DroidCamX) is installed on the smartphone from the store and launched. If WiFi is active on the smartphone, DroidCamX shows the IP address that is assigned to the smartphone and port 4747. If you run the Droidcam client on a computer with Mageia-8, you can immediately connect to the smartphone camera via WiFi. The second connection option is via adb and a USB cable (USB debugging mode is enabled on the smartphone, the smartphone must be connected and authorized, see the screenshot in the attachment).

The external microphone is used in Linux for this reason: https://github.com/dev47apps/droidcam/issues/43

However, today there are successful attempts to use a microphone built into a smartphone...

Connecting a microphone from a smartphone (droidcam_audio):
---
After launching DroidCamX on a smartphone and the Droidcam client on Mageia-8, you need to do this:

[[ $(pactl list | grep droidcam_audio) ]] || pacmd load-module module-alsa-source device=hw:Loopback,1,0 source_properties=device.description=droidcam_audio 

...and the microphone will appear as "droidcam_audio".

Microphone Test (droidcam_audio): http://webcammictest.com/check-mic.html

Additional information:
---
https://github.com/dev47apps/droidcam/issues/54
https://github.com/dev47apps/droidcam/issues/60

Morgan, I hope it will be interesting for you to dig into Droidcam; we all need to have some fun sometimes... :)

p.s. a fly in the ointment... I was never able to get the microphone to work without additional manipulations. Something should be started first, something second, something third: the videodev kernel modules, v4l2loopback_dc, snd_aloop, Droidcam itself and the droidcam_audio device addition command. I have already tried all the recommended methods, but I can't do without manual intervention. If you suddenly figure out the microphone, we can collect full-fledged packages for Droidcam as well.

Kind regards,
Alex

Created attachment 12860 [details]
droidcam-v1.7.3_screenshot

Interesting! Will maybe try later.

Here at east coast in south end of Sweden summer is perfect - for vacation. I need vacation from "libre" duties, catching up with family, social life and then work.

I suggest you put a note on the Mageia forum so more people will know.

Regarding android-tools, if you like, maybe ask David if you can become the packager for it.

(In reply to Morgan Leijström from comment #56)
> ...
> I suggest you put a note on the Mageia forum so more people will know.
Hi, Morgan. I took your advice: https://forums.mageia.org/en/viewtopic.php?f=10&t=14250 If you have free time, come visit. Thanks... :)

Hi, David GEIGER. I am happy to inform you that a release has been released android-tools-v31.0.2 (Unoffical CMake-based build system for android command line utilities): https://github.com/nmeum/android-tools/releases/tag/31.0.2

Prior to the release of v31.0.2, participants in this discussion were engaged in testing related fixes. The history of all changes was collected here: https://github.com/AKotov-dev/android-tools-rpm

God knows, we all tried our best. :) I hope that this will additionally help you to release the new android-tools v31.0.2 package.

With best regards,
Alex

Ping...?

(In reply to Morgan Leijström from comment #59)
> Ping...?
android-tools v31.0.2 for Mageia-9: https://cloud.mail.ru/public/njgN/Csq8ZuUbn

Hello, Morgan. This may be useful for testing in the future. :)

Thumbs up
But we need to fix the problems for Mageia 8 where the users are ;)

@Morgan
Probably David Geiger has an important job right now and he is busy. Now many people have more problems with the pandemic: business, partners, rent, logistics, etc. I miss him too and hope that he will find time soon. :) In Russia, the pandemic has also made its own adjustments: the industry has stopped, everyone has switched to remote connection, even drunken bears in earflaps have stopped riding bicycles and playing balalaika on the streets. Now only sober bears are driving. :(

The spec file contains 4 more maintainers, starting from April 2014: umeabot, cjw, joequant, akien. We still have Thomas Backlund, maybe we should contact him (if he doesn't send us)?

tmb Thomas is back doing great and heavy work on kernel and stuff, we should not load him more.  akien Rémi have already a load of packages and is stepping back.   uemabot i think is a rebuild script. I dont know if joequant is still on, but CC him and cjw, and our new packager Philippe Didier in case he happen to like to work on this.

And setting asignee for now to anyone.

CC: (none) => cjw, joequant, joequant, philippedidier
Assignee: geiger.david68210 => pkg-bugs

@Morgan (the latest news...)
ArEditor-v1.4: https://github.com/AKotov-dev/areditor/releases

In this version, parsing has been improved: 3 search templates + search inside GOTO/LABEL blocks) and an environment variable selection list (ENV) has been introduced. Additionally, I wrote to the upstream "android-udev-rules" for M0Rf30 and there is an interesting discussion about the modernization of the rules: https://github.com/M0Rf30/android-udev-rules/issues/215 . If you wish, join us.

I also asked at "pkgs.org" those who already use android-tools-v31.0.2: Solus, openSUSE Tumbleweed, Fedora, Arch Linux. Also, they all already use the new 51-android.rules, i.e. exactly the one that we tested here. The only difference is that 51-android.rules is designed as a separate package in other distributions. Our rules are located directly in the android-tools package. In general, we were going in the right direction, Morgan. ;)

Sincerely,
Alex

Nice check up and update Alex :)

It may be a good thing to package the rules separately.  Easier for users to update it in another way if we Mageia fall behind in the future.

@alex: Cristian want to become a packager, so was thinking maybe you two could cooperate on this bug, if cristian would like, and find someone to mentor.

@christian, Here is another bug in similar status as the Nextcloud one, and seem to be within your interest sphere.  Alex here already build working packages better than we have released, plus extra tool, but we need someone to eventually package it officially. I got the idea it may be some exercise for you, if you find someone to mentor this process.  If so begin with asking David GEIGER, se comment 7 to 14.

CC: (none) => chb0

(In reply to Morgan Leijström from comment #65)
> @alex: Cristian want to become a packager, so was thinking maybe you two
> could cooperate on this bug, if cristian would like, and find someone to
> mentor.
Thumbs up. I am completely sure that we will definitely make friends with Christian and discuss all the questions that arise regarding this bug. :)

Cristian, I apologize for the typo. Again, this online translator corrects what is not necessary. The developer of this "translator" needs to be isolated from society. :)

Hi Alex. No worries, Christian is the right spelling. ;)

Thanks Morgan for believing on me and be so supportive :)

Nicolas has accepted to mentor me for Nextcloud. 
I can also look at what’s going on here.
There is a long history I need to catch up though. 

In order not to promise too much, give me a week to look at this. 
Alex looks so engaged, I don’t want to disappoint him. 

Kind regards.

Hi, Christian. :)
Since Morgan recommended making the rules "51-android.rules" a separate package in comment #65 , I decided to simplify the task a little for all of us and put together a separate package of rules "android-udev-rules". It is located in the same place as everything else: https://github.com/AKotov-dev/android-tools-rpm

The issue of including the rules in a separate package, which is not in the Mageia repository, will probably require coordinating this with your mentor or with Morgan, who is probably also aware of this procedure. To be honest, I do not know what kind of chain of approvals the Mageia policy implies, but I understand that in theory it should be.

If you need anything, please write. I am always happy to discuss something further.

Regarding "disappointments" - this is not our method. :) You will definitely manage! As the French say: "Vive la résistance!". ;)

Sincerely,
Alex

Hi,
sorry for my delay. 
The thing is, I have initiated too many things in parallel, and I need to close some before taking something else.
That being said, as it looks like Alex as almost done everything, won't be more efficient the official packager / maintainer has a quick look and put it in Testing, after endorsement?

Sorry again not to be able to do more on this right now.

/Christian

Hi, Christian.
I am very glad that you are in touch! However, I suspect that different girls distract you from your favorite business. Oh, these women... ;)

Thank you so much for not refusing to help. Of course, now you have a difficult period (no kidding). As I understand it, you are suggesting to give a packages on this topic to your or another mentor/maintainer for verification? Hmm... In this case, I suggest checking what will already be unambiguously intended for the Mageia repository, i.e. all packages in a complex with the necessary fixes: cross-dependencies, prefixes (mga), the probability of the build in Mageia-8 and Mageia-9 (I remember that David Geiger uploaded them immediately to both M8 and M9). :)

The main thing:
---
Archive rpmbuild-3-package-for-android-m8-m9.tar.gz contains 3 spec/source for three packages at once: android-tools, android-udev-rules, areditor (the latter is at your discretion): https://github.com/AKotov-dev/android-tools-rpm/raw/main/rpmbuild-3-packages-for-android-m8-m9.tar.gz

What's new:
---
In the package android-tools taken into account the fact that the 51-android.rules moved in the package android-udev-rules. android-udev-rules now writes the rules in /usr/lib/udev/rules.d/51-android.rules (basic) and creates a group "adbusers", while being in (Requires:) in the package android-tools, because rules are pulling for the group to which must be added the user and may be different. For example, in the rules from Fedora, the main group was usb.

Result:
---
There is only one thing left to do: cd ~/rpmbuild/SPECS; rpmbuild -ba ./*.spec

Sincerely,
Alex

(In reply to Alex Kotov from comment #71)
> 
> Result:
> ---
> There is only one thing left to do: cd ~/rpmbuild/SPECS; rpmbuild -ba
> ./*.spec
> 
> Sincerely,
> Alex

Hi Alex.
It is exactly what I meant. There is nothing to do but pushing it for testing (after, of course, a quick look and confirming it builds).
As I am not allowed to publish myself and as an official package will anyway have to look at the spec as well, I really don't see the point for me to step in.

The best is an official packager takes care of it directly.

BR
/Christian

@Christian
I wish you a successful completion of all activities related to the assembly of packages and training. May the Force be with you.

ВR
/Alex

Questions waiting for answer:


__Packager

@David GEIGER : Do you wish to remain packager or wish to hand over, and if so are Christian willing (I think so?) to take on updates of this package(s) in the future?


__Decisions to be made by packager

Decisions to be made by whoever is to be the packager for times to come, and the previous/current packager please advise wisely:

§ Keep current rename of fastboot-android to originally fastboot, first above in comment 7, bug 24139

§ Split out the rules "51-android.rules" as a separate package ?

§ Anything else?

upd: 01.11.2021
---
android-tools-31.0.3 and android-udev-rules mga8: https://github.com/AKotov-dev/android-tools-rpm

upd: 13.01.2022
---
1. android-tools-31.0.3p1-1 (Mageia-8/9, x86_64, rpm, src.rpm)
- Fixes boringssl build failure with GCC 11.2.1
- Add boot.img manipulation tools
- Add Dynamic Partition Tools
- added utilities:
   /usr/bin/lpadd
   /usr/bin/lpdump
   /usr/bin/lpflash
   /usr/bin/lpmake
   /usr/bin/lpunpack
   /usr/bin/repack_bootimg
   /usr/bin/unpack_bootimg


2. android-udev-rules-20220102-1 (Mageia-8/9, noarch, rpm, src.rpm)
+ Alcatel 1 2019 5033F
+ Android accessory mode
+ Ascom vendor
+ 5 Ascom devices
+ Asus ZenFone 2
+ Razer Phone 2 ADB mode
+ Sony Ericsson Xperia Z Ultra
+ Xiaomi Redmi Note 8T
+ ZTE P685M LTE Cat4 modem
+ T & A Mobile rules

GitHub: https://github.com/AKotov-dev/android-tools-rpm

Thank you Alex

I cant test myself currently

Hoping this can get into Mageia soon.

@Morgan Leijström
No problem, Morgan. :) Until David (or another maintainer) shows up, updates will continue, because now the situation is such that can't lose this thread. Otherwise, then its end will not be found to unravel the tangle.

By the way, ArEditor-v1.5 was also updated yesterday (see Releases): https://github.com/AKotov-dev/areditor

I added a reverse search in the file /etc/udev/rules.d/51-android.rules. Now you can additionally search for what you need in manual mode. For example, idVendor/idProduct or identify duplicates in rule blocks, etc. Finding duplicates turned out to be a very fun activity. :) Yesterday I talked to M0Rf30 (Gianluca Boiano) - one of the developers of 51-android.rules just about this, it was interesting: https://github.com/M0Rf30/android-udev-rules/issues/219

M0Rf30 has made a good additional Wiki on 51-android.rules, if interested: https://github.com/M0Rf30/android-udev-rules/wiki

In general, the team of developers (JoesCat, M0Rf30 & Co) it turned out to be very interesting. The guys are happy to accept idVendor/idProduct of new models of Android devices and are generally very willing to get in touch. If you have a desire, join us.

There is no more news about Android yet. Good luck, my friend! ;)

Sincerely,
Alex

This package risk getting dropped
https://bugs.mageia.org/show_bug.cgi?id=31122#c3

@ Christian & Alex
Maybe you can step up, maybe together

Alex seem to know how to handle it but do not want to be a packager (still?)

Hi. Hope I am not promising too much…
I will try to update to 33.0.3 for MGA9 next week.

Wonderful :)
Trying is at least half the effort!

Are you trying to fix all ?

Bug 24139 - Rename fastboot-android into just fastboot
Bug 29157 - fastboot-android fail to use mke2fs
Bug 31122 - android-tools new security issues

(In reply to Morgan Leijström from comment #81)
> Wonderful :)
> Trying is at least half the effort!
> 
> Are you trying to fix all ?
> 
> Bug 24139 - Rename fastboot-android into just fastboot
> Bug 29157 - fastboot-android fail to use mke2fs
> Bug 31122 - android-tools new security issues

Hi Morgan 
If I start, I will finish it all ;)

Hi

kekepower has already updated to 33.0.3 in Cauldron, using the same 51-android.rules 

I don't want to interfere and to mix things up. 

I will ping him on IRC to know here what his plan is.

Great.
Wonder if he have looked at any of this bug and others in comment 82, or just updated.

ping.

Hi. Have you tested the Cauldron update?

We stopped supporting Mageia 8 almost 8 months ago 
https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/

That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not.

If this particular bug did not get fixed for Mageia 8, then we do regret that.

If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field.

If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing
Mageia is a community project, meaning that we, the users, make Mageia together.

The more active contributors we have, the more bug reports will get fixed.
Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D

Resolution: (none) => OLD
Status: NEW => RESOLVED