(Ich werde dies zu einer Antwort machen und ergänzen, auch wenn ich keine fertige Lösung habe. In den Kommentaren ist das einfach zu umständlich.)
Das Problem ist nicht udevso, dass "Debugging udev" nicht helfen wird. udevreagiert nur auf das Signal, das bei .408114 vom Kernel kommt.
Angenommen, es gibt keine anderen Nachrichten, dmesgals Sie gezeigt haben (was bedeutet "keine", nicht "keine, von der Sie denken, dass sie verwandt sind", andernfalls bearbeiten Sie bitte die Frage mit dem Teil vor und nach Ihrem Snippet) versucht, Befehle an die Smart Watch zu senden, um mehr über das Speichergerät zu erfahren, und beide (Schreibschutz und Cache) schlagen fehl. Danach führt der Kernel möglicherweise mehr Interaktion aus und entscheidet schließlich, dass dies kein USB-Speichergerät ist, da er nicht antwortet oder Fehler zurückgibt. Der Kernel entfernt ihn also von der Speicherebene, sendet ein Signal an udev, udevtut was er soll und entfernt die Geräteknoten. Selbst wenn Sie das udevEntfernen der Geräteknoten verhindern möchten, sind sie nicht auf der Kernel-Ebene vorhanden, daher sind sie unbrauchbar.
Was Sie tun können, ist, um usbmondie USB-Pakete zwischen dem PC und der Smartwatch zu erfassen. wiresharkkann das interpretieren. Wenn Sie dies debuggen möchten, müssen Sie wissen, wie USB funktioniert, wie USB-Speicher funktioniert und wie die SCSI-Befehle funktionieren, mit denen die USB-Speicherebene funktioniert. Dies kann einen Hinweis darauf geben, was schief geht. Die Standards sind nicht schwer zu finden und ein bisschen googeln.
Es ist auch möglich, dass die billige Smartwatch den USB-Speicherstandard nicht richtig implementiert und einen speziellen Windows-Treiber hat, der vom Hersteller geschrieben wurde, was diese Tatsache verbirgt. In diesem Fall können Sie auch den USB-Datenverkehr unter Windows ausfindig machen, um herauszufinden, wie es funktioniert. Dann müssen Sie jedoch einen eigenen Linux-Kernel oder einen eigenen Userspace-Treiber dafür schreiben. Dies ist eine Menge Arbeit.