@AndrewBloom have you considered usinghttps://github.com/libusb/libusb-cmake instead of sample you gave?

@Youw, thanks for your comment. I didn't know the existence of that project. I looked at it, and there is a difference on the approaches to the problem. The project you mentioned, tries toredo the build process using Cmake. This can lead to misalignments betweenlibusb and their cmakelists file. For example, if a file is added tolibusb source, the same has to be added on their cmakelists. The approach I documented, instead, simplydelegates the build to the official build system. It's the equivalent of, in plain english, "please build it and give me the result". The risk of misalignment this way is eliminated, as long as the top part of this readme is valid (instructions on how to build usingndk-build).
IMO, given the fact that Android native development relies now oncmake, and 99.9% of android developers use Android Studio, the added information is extremely valuable in reducing the integration time between a new project andlibusb, minimising the risk of unforeseen side effects. Moreover, the code includes some quirkiness that took me days to discover (the use ofBUILD_BYPRODUCTS needed to make it work withninja is far from obvious).
I thought to share my findings so to save some other people's time when facing the same issues, but if you think it is out of scope feel free to discard the pull request.

This can lead to misalignments between libusb and their cmakelists file. For example, if a file is added to libusb source, the same has to be added on their cmakelists.

I'm maintaining that project, and making sure that won't happen. CI helps me a lot with that.

@Youw, I'm glad to have the chance to speak with someone that maintains that project. I appreciate your effort in giving to the community aCMakeLists to compilelibusb using only thecmake build system. I can indeed imagine some scenarios wherecmake is available on thehost system, but the build system supported bylibusb is not, and suchCMakeLists is necessary. But in the general case, your approach adds complexity, and so potential failures. It's a build system supporting multiple architectures, and you need to duplicate everything on theCMakelists. As a user, I want to be sure that every compilation or optimisation flag or quirkiness is used when I compilelibusb, and that guarantee is given only using the official build system. The simplest and easiest solution, IMO, is todelegate the build process to the official supported build system. Thankfully, usingExternalProject functionality incmake, this is possible. Actually, the same approach could be used for other OSes, and I leave it to you to evaluate the pros and cons in that scenarios. For Android, I can attest first hand that it delivers its benefits in a concise and elegant way.

@AndrewBloom I get your points.
Still, if you don't mind me asking, I'd like to hear if as simple asadd_subdirectory(libusb-cmake) worked in your environment at all. A small feedback to help improve the project if anything is needed.

github doesn't make it easy to diff this. It just shows one file deleted, and one new file with all new contents.

Can you please make a separate PR that only renames the file? That should be easier to get approved and merged. Then you can rebase this one, and reviewers can see what you actually changed.

@seanm I admit that renaming and modifying the file in the same commit was terrible and I had too to double check the changes line by line myself. Sorry it's my first pull request to an open source project :)
I did a new branch on my fork and only renamed the file there, then I rebased the patch-1 branch to that branch on my local machine and pushed forced the changes on my forked repository, and it appears that the pull request is now updated to reflect that, without me explicitly asking for it.
Unfortunately the diff is still not super useful.
Consider that I used ChatGPT to change the file to md format (basically adding the formatting for headers and such) and despite I asked explicitly to not change the contents, it took some liberties and reworded a couple of phrases. These AIs are becoming more and more rebellious.
I checked the content and everything should be there, hopefully you'll confirm that there is no significant changes too.
Ps. at least looking at the second commit you'll see the diff side by side, but it still gives all lines changed.
here:https://github.com/AndrewBloom/libusb/tree/patch-1/android you can see how the file is displayed as markdown, I think it looks clearer but I agree it's quite subjective.

@Youw I'll try thelibusb-cmake project tomorrow and let you know the results.

@Youw I switched tolibusb_cmake on my project and it runs. Consider that my project currently is nothing more than a sketch, that takes the fd from android and passes it to the lib. I added the logging fromunrooted_android.c just to push it a bit further and they are printed. It's definitely far from being a thorough test, sorry I can't be more helpful.

@seanm I added a 3rd commit, because testing the sample code there was a wrong type and compiler error. I guess that the right parameter is NULL for that function as it is used inunrooted_android.c, but I didn't track down the call on the source code to be 100% sure.