This makes Android ask the user whether they want to delete user
data when uninstalling the app instead of always deleting user data,
which is pretty great now that we're forced to use scoped storage.
It only works on Android 10 and up, though.
When I made 9c8bb24, I assumed it was completely impossible for a
non-preloaded app to access the entirety of the Android/data/ folder
on Android 11. This turned out to be false. While you can't access
the directory without using SAF (even if you have the Manage All
Files permission), and the user can't navigate to the folder using
the SAF folder picker, what you can do is pass the Android/data/
folder as an EXTRA_INITIAL_URI to the SAF folder picker. If the
user then presses "use this folder" without navigating out of the
folder, the app will be able to access the folder using SAF.
So what does that mean for Dolphin? It means scoped storage is a
little less bad than I feared, and I have a string to adjust.
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.
Apparently some phones (at least some from Samsung) don't expose the
system file manager in the system settings despite it being the
only on-device file manager that can open app-specific directories...
The following settings are currently not SAF compatible,
and might never be due to the performance impact:
Dump Path
Load Path
Resource Pack Path
Wii NAND Root
This commit makes us show a message to the user if they try to
change one of these settings while scoped storage is active.
I don't want to entirely remove the settings from being listed
in the settings activity, because it's important that the user
is able to reset them if they were set to something custom in
a previous version of Dolphin.
This lets Dolphin function without the user granting access to
external storage. We need this for scoped storage compatibility.
When scoped storage is not active, we still ask for permission to
access external storage the first time the app is started so that
we can use the existing dolphin-emu folder if there is one. But
if it doesn't exist, or the user denies the permission, or scoped
storage is active, the app-specific directory will be used instead.
The same kind of change as the changes made in the previous
commit, but this change is more involved, in particular because
of how SyncProgramsJobService was using display names as keys.
Many Android users want to disable SyncOnSkipIdle as a performance
hack, to the point where it's often suggested as something to
paste into Dolphin.ini (if not to use a fork). If adding it as
a setting in the GUI gives us an opportunity to explain what the
setting actually does and stops people from pasting stuff they
don't understand into INI files, I think it can be worth adding
despite how it can make games unstable. It not being in the GUI
doesn't seem to be stopping people from disabling it anyway.
The added setting in the GUI is a three-way setting called
"Synchronize GPU Thread" with the following alternatives:
"Never": SyncGPU = False, SyncOnIdleSkip = False
"On Idle Skipping": SyncGPU = False, SyncOnIdleSkip = True
"Always": SyncGPU = True, SyncOnIdleSkip = True
See PR 8203 for background on the game INI deletion prompt.
It's been almost two years since PR 8203 was merged, so you
would think that people are no longer creating game INIs that
contain a copy of every global setting, right? Unfortunately,
MMJ was forked not too long before that and never backported the
change, so right now there's a not insignificant number of people
online posting game INIs full of this garbage for others to use.
One thing that's been missing from the game INI deletion prompt
is a description of what the problem with having tons of extra
lines in a game INI actually is. This change adds that, in the
the hope that it will make people ignore the warning less often.
This option does in fact not enable and disable logging as a whole.
You can get logs through logcat regardless of this setting.
Also taking the opportunity to remove the reference to
the "dolphin-emu" folder name since we will no longer be
using that folder once scoped storage is applied to Dolphin.
Added Opacity controls for the user to customize the opacity of their touchscreen controls. Also, placed both Scale and Opacity settings into one window/option called Adjust Controls.
In 8c723d0, I intended to update the main activity, emulation
activity and game properties dialog, but I forgot to actually
update the game properties dialog. This commit fixes that.
The changes outside of GamePropertiesDialog.java are just
to hide the Wii controller settings for GameCube games.
Basically, instead of having one button for config, one button
for graphics settings and so on, we now have just one settings
button which takes you to a screen where you pick between
config/graphics/GameCube controllers/Wii Remotes.
The main reason I want to do this is because people still have
trouble finding Overlay Controls in the "new" in-game menu.
Typically (depending on the screen size and the length of the
game name), the scrollable part of the menu can fit 4 items,
and merging Config and Graphics Settings into one item would
move Overlay Controls from 5th place to 4th place (assuming the
user doesn't have savestates enabled), which makes it findable
even for users who don't realize the menu can be scrolled.
The dialog that's shown when long pressing a game in the game
list is also shortened. While not a pressing matter, I think
it was getting a bit long.
An additional reason to do this is because we probably will
want to make it possible to edit the controller settings
from the in-game menu at some point in the future. With the
old approach, this would require us to dedicate a whopping 4
menu items just for settings (not including Overlay Controls),
which I think is excessive.
