Note: By "HandleInit" in this commit message, I mean the code that is
in HandleInit in master except the part that launches EmulationActivity.
In other words, I mean the call to SetUserDirectory and the call to
DirectoryInitializationService.startService. Couldn't think of
something more accurate to call that than "HandleInit"...
In master, HandleInit only runs when the main activity is launched.
This is a problem if the app ends up being launched in some other way,
such as resuming EmulationActivity after the app has been killed in
order to reclaim memory. It's important that we run HandleInit, because
otherwise the native code won't know where the User and Sys folders are.
In order to implement this, I'm dropping the ability to set a custom
User folder in an intent. I don't think anyone is using that anyway.
It's not impossible to support it, but I can't see a way to support
it that doesn't involve something ugly like having code for calling
HandleInit in every activity (or at least MainActivity + TvMainActivity
+ EmulationActivity, with more activities potentially needing it in
the future if we expand the usage of native code for e.g. settings).
If we want to support setting a custom user directory, we should
consider another way to do it, such as a setting that's stored in
getFilesDir() or getExternalStorageDirectory(). Intents are intended
to control the behavior of a specific activity, not the whole app.
There are two reasons for this change:
1. It removes many repetitive lines of code.
2. I think it's a good idea to enable the use of old-style section
names even for settings that previously haven't been settable in game
INIs. Mixing the two styles in INIs (using the new style only for new
settings) is not ideal, and people on the forums don't even seem to
know that the new style exists (nobody knew a way to set ubershader
settings per game, for instance). Encouraging everyone to start using
only the new style might work long-term, but it would take take time
and effort to make everyone get used to it. Considering that this commit
*reduces* the amount of code by adding the ability to use old-style
names for more settings, I'd say that adding this ability is worth it.
You will see an empty gc pad settings screen until you open any other
settings screen and change something, at that moment the Dolphin.ini will
be created and the gc pad settings will be loaded successfully the next
time you open the screen.
This fixes the bug by putting the default gc pad settings section even if
the Dolphin.ini file doesn't exist
Trying to force the XSI version by undefining _GNU_SOURCE can lead
to compilation errors on some systems because of headers expecting
that _GNU_SOURCE is defined.
This commit uses define checks to detect which version we have.
I tried making an overloaded function (int and const char*) instead,
but that led to a warning about one of the variants being unused.
This solves the following issues:
1. If user uninstall Dolphin and install it again the resources will
not be copied unless the user manually clear the app cache because we
are enabling the allowBackup flag in the manifest which will make the app
restore the settings saved in the shared prefernces including the flag
assetsCopied. This PR always copy the files everytime you open Dolphin.
2. If the AssetCopyService took long time and you tried to open the settings
screen or start a game the behaviour was not expected or the emulator will
crash, this PR make sure that whatever we add to the DirectoryInitializationService
or how long it will take will still work as expected by blocking both
the settings screen and the emulaion screen to wait untill all resources
needed are copied.
3. Better communication between the DirectoryInitializationService and the
UI screens using brocast messages.
Leo Lam