Hashlist of allowed adb version? WTF

[jpstotz]

I have Android Studio installed and thus always latest adb version (currently Android Debug Bridge version 1.0.41 - Version 37.0.0-14910828).

When I have to select the adb executable at start-up ADB Explorer just fails with a totally wrong error message:

"Could not get ADB version from provided path." (got it from the source code, the German version ADB Explorer showed to me was even more weird).

That leads me these questions:

1. Do you really maintain a white-list of adb versions that should be used with ADB Explorer? IMHO this is a bad as it is every new adb version (which is release every few weeks) breaks ADB Explorer. So do you really plan to release a new ADB Explorer version every time Google releases a new adb version? (also keep in mind that there might be a arm64 version of adb.exe soon, so twice the work to maintain this list).
2. Why isn't there a LOG displaying the steps done or at least an error message that actually explains what is going wrong. In my case Your ADB version is unknown/unrecognized - we don't allow unknown adb versions
3. Why isn't there an option to override the check at your own risk?
4. Displaying error message only in the local language is great for the user but bad for the development and issue tracking. IMHO you should always also display something language independent like the message ID S_MISSING_ADB_OVERRIDE to make it possible to search for an issue in the project issue tracker.

The common way I would have expected to get the version of adb would be executing adb --version and parse it or connect to TCP 5037, send the adb version command and check it.

BTW: The alternative installing a specific adb version just for ADB Explorer isn't a good idea, too. Using multiple adb versions means they kill each other at run-time, interrupting what ever adb is performing at that moment. To my experience adb works best when there is only one adb version per Windows installation.

[Alex4SSB]

Thanks for the info - the new version isn't visible on the official download page which caused the issue. The version scraper also has been fixed and changed to run 3 times a week to check for new versions. That is the temporary fix to the current method.

The method will be changed as well to be more future proof.

An option to override security check will be added as well, and it will not be a part of the regular settings file.

The error handling will be improved to make it clearer that the security check failed.

An English error code will be added to errors.

Regarding translation - if you noticed an error, it would be very helpful if you could fix it on Weblate.

[jpstotz]

This project really seems to have a history with problematic adb versions if you added such a mechanism. As you use file hashes I assume the version info of adb wasn't enough to detect the problematic versions?

If it is only the version check for adb 31.0.2 have you considered using the date of the Authenticode signature of adb.exe? Normally Google doesn't publish old versions of adb thus the version check for 31.0.2 should be equivalent for checking if the adb.exe signature was created after a certain date.

Regarding the translations I will take a look onto it. However the translations can only be as good as the "source language" (I assume that is English?).

[Alex4SSB]

The hash check was added not due to bad versions, but rather as a fix for a security vulnerability - trying to execute whatever was provided as the ADB path (even for version check), which can be overridden in the settings file, allowing execution of malicious files by the unsuspecting user.

One of the changes that will be implemented is indeed the verification of the certificate, which Google started signing since ADB 34.0.5 (prior versions can use my hash list).

The source language is indeed English.

Also, if you set manual ADB path to %LocalAppData%\Android\Sdk\platform-tools\adb.exe now, it will work with ADB 37.0.0 since it is now in the online list.