The main activity loads settings essentially as soon as it
starts, in order to determine which tab to show. If the process
of stopping emulation has not finished at this point, a race
condition may be triggered where two IOS kernels are created
at once due to the emulation thread loading or saving the
SYSCONF while the GUI thread is loading the SYSCONF. To fix
this, we can wait for emulation to fully end before returning.
Because this race condition is hard to reproduce, I have not
been able to test that this actually fixes the race condition,
or even that the cause of the race condition is exactly what I
believe it is. But I am relatively confident.
I was hoping we would be able to pull in the default values
from C++, but it seems like more trouble than it's worth,
partially because of different settings having default values
of different types and partially because we don't have any
convenient way to get a list of all C++ settings.
The functions with "UTF" in the name use "modified UTF-8" rather
than the standard UTF-8 which Dolphin uses, at least according
to Oracle's documentation, so it is incorrect for us to use them.
This change fixes the problem by converting between UTF-8 and
UTF-16 manually instead of letting JNI do it for us.
Currently, the touch controller overlay uses a square gate for
sticks. This commit changes that so that it instead uses the
stick gate configured in the INI, which ensures that the values
sent to the core are appropriately scaled regardless of what
is configured in the INI and makes the overlay look nicer
if the INI is set to a stick gate that matches the graphics.
The workaround was added in 0446a58.
The underlying problem is that we must not destroy the surface
while the video backend is initializing, otherwise the video
backend may reference nullptr.
I've also cleaned up the logic for when to destroy the surface.
Note that the comment in EmulationFragment.java about only being
able to destroy the surface when emulation is running is not true
anymore (due to de632fc, it seems like).
This feature was originally exclusive to the previous iteration of
DolphinQt (the one that was the reason for the current iteration
being named DolphinQt2 initially).
https://bugs.dolphin-emu.org/issues/8949
Much of our native code assumes that UICommon::Init has been called
(for reasons such as wanting to access the user's settings),
so not calling it until emulation start heavily limits what native
code we can use in the Android GUI (except during emulation).
Léo Lam