By using the title database we ship with Dolphin, we get more uniform game titles than if we grab what's in each game's opening.bnr file. It also becomes possible for users to supply a custom titles.txt file. This has been implemented in DolphinQt since a long time ago.
Unlike in DolphinQt, there isn't much space to show playtimes directly in the game list, so I've put it in the game details dialog instead.
This gets rid of the last Android-specific code that directly interfaces with INI files.
If we're in a function that isn't just going to immediately return to Java, leaking local references can lead to problems eventually.
These files cannot compile correctly as C, so there's no reason to have ifdefs for C compatibility. We switched to not checking the __cplusplus macro in our JNI code some time ago, but it seems like I forgot to remove it from these two files.
Yes, that's right! It's time to add even more NKit warnings, because users still don't understand what NKit is or how it works! More specifically, some users seem to be under the impression that converting an NKit file to for instance RVZ using Dolphin's convert feature will result in a normal RVZ file, when it in fact results in an NKit RVZ file (since NKit is not a container format in the sense that GCZ/WIA/RVZ/WBFS/CISO is, but rather a kind of trimmed ISO). I can hardly blame users for not knowing this, because it's not intuitive unless you know the technical details of how NKit works.
FindAllGamePaths may take a little while, and holding the gameFileCache lock isn't actually necessary until it's time to put the results returned by FindAllGamePaths into gameFileCache. The downside of this change is that we have to do an extra round of JNI in between FindAllGamePaths and Update, but I don't think that's much of a problem.
SPDX standardizes how source code conveys its copyright and licensing information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX tags are adopted in many large projects, including things like the Linux kernel.