Hello! I know that Android is not officially supported yet, but I want to try to make several tables for this platform (it could be usefull someday). I will make a blueprint to deal with this. But first I want to know whether my code is correct before doing other tables. I made a table for Android that queries an important file called packages.xml (all information about the apps on the system). It is needed to be root on the phone to get reponses for those table, but I will try to make tables to get other usefull information on the system without being root. So if you see something wrong in the code, please tell me
07/01/2021, 10:48 AM
Really neat to see this!
Review code in a screenshot is hard. Style wise, I see a couple of places I'd recommmend an early return. Some function names that still have test in them... A general question is whether to make new tables vs use existing ones. There's a strong bias to using existing ones, you get a lot of power that way. But apps/programs/etc might be so different on android it merits it's own table. I don't know enough. other small things like the columns names should probably be different. We don't use camelcase, and things should generally conform to other things. Ie: path, not codepath
Not sure what people think about merging in android tables.
07/01/2021, 11:30 AM
Thank you seph! I take your advice into account. I know it is a bit early to talk about android tables, but I just want to make a demonstration with few relevant tables
I think it's fine for discussion but I would not merge code until the following requirements are met:1. Integrate the NDK toolchain
2. Rework (if needed) how the daemon works so that it can be integrated as a service on Android
3. Add CMake support for disabling the tables that are not required (or are not working) on Android
4. Libraries used by disabled tables should no longer be referenced by find_package
5. Add packaging support