Apparently there are phones where accessing Dolphin's app-specific
directory isn't just annoyingly hard but actually impossible.
To give users of those phones at least some kind of way to manage
their data (even if it's a lot less convenient than if we were
allowed to let the user open the app-specific directory in a
file manager), I'm adding a way to export the directory to a
zip file and then import it back.
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.
We don't have a timeout like this on other platforms, and it doesn't
accomplish anything useful as far as I can tell. If you trigger it,
all that happens is that you don't get a working game and also can't
press Exit Emulation without Dolphin hanging (stuck in Core::Shutdown).
* Disabled: disables the overlay pointer
* Follow: default behaviour, IR pointer follows touch position
* Drag: IR pointer moves relative to the initial touch event position
Fixes a crash that could occur if the static constructor function for
the MainSettings.cpp TU happened to run before the variables in
Common/Version.cpp are initialised. (This is known as the static
initialisation order fiasco.)
By using wrapper functions, those variables are now guaranteed to be
constructed on first use.
It's a complete coincidence that both SIDEVICE_GC_CONTROLLER (6)
and SIDEVICE_WIIU_ADAPTER (12) are divisible by 6. Dividing
by 6 because of that doesn't make sense, especially not if we
want to add support for more kinds of SI devices on Android later.
Turns out that most phones ship with a special Google version of
DocumentsUI instead of just using the AOSP version, despite the two
being pretty similar as far as I can tell. This change makes us
check for both package names instead of just the AOSP package name.
Netplay: Fix possible Wii save restore race condition between Netplay and CPU threads on game shutdown by making the Wii Save Sync data part of the BootParameters.
I haven't fully confirmed why the previous commit broke this,
but I imagine it's due to AfterDirectoryInitializationRunner
executing in a different order than before, resulting in
startRescan running before startLoad.
This decreases our APK size by a few megabytes. Most of the reduction
is from Java libraries that we only use small parts of. Code shrinking
gets rid of all the unused code from these libraries from the APK.
Because I highly value the ability to get stack traces that make
sense, I have specifically disabled obfuscation (automatic renaming
of symbols to short incomprehensible names).
I've only enabled code shrinking for release builds, purely because
I feel like the extra build time (30 seconds on my machine)
would be annoying when you want to make debug builds rapidly.
This commit changes the default value of Fast Texture Sampling to true, and also moves the setting that controls it to the experimental section of the advanced tab. This is its own commit so that it can be easily reverted when we want to default to Manual Texture Sampling.
Co-authored-by: JosJuice <josjuice@gmail.com>
Gets rid some uses of the deprecated LocalBroadcastManager.
One note about the changes in GameFileCacheManager itself:
The change from compareAndSet to getValue followed by
setValue is actually safe, because startLoad and startRescan
only run from the main thread, and only the main thread ever
sets the flags to true. So it's impossible for any other thread
to change the flag in between the getValue and the setValue.
The past few Android releases have been adding restrictions
to what services are allowed to do, for the sake of stopping
services from using up too much battery in the background.
The IntentService class, which GameFileCacheService uses,
was even deprecated in Android 11 in light of this.
Typically, the reason why you would want use a service instead of
using a simple thread or some other concurrency mechanism from the
Java standard library is if you want to be able to run code in the
background while the user isn't using your app. This isn't actually
something we care about for GameFileCacheService -- if Android wants
to kill Dolphin there's no reason to keep GameFileCacheService
running -- so let's make it not be a service.
I'm changing this mainly for the sake of future proofing, but there
is one immediate (minor) benefit: Previously, if you tried to launch
Dolphin from Android Studio while your phone was locked, the whole
app would fail to launch because launching GameFileCacheService
wasn't allowed because Dolphin wasn't considered a foreground app.
Unlike with Android 11, there should be no downsides to doing
this, so we might as well get this out of the way early.
The main part of the work was already done in 5a1a642.
This should make C++20 and std::filesystem work. (Not that
we really can use std::filesystem much on Android since
it doesn't work with scoped storage...)
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.
This replaces the MAX_LOGLEVEL define with a constexpr variable
in order to fix self-comparison warnings in the logging macros
when compiling with Clang. (Without this change, the log level check
in the logging macros is expanded into something like this:
`if (LINFO <= LINFO)`, which triggers a tautological compare warning.)
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.
The purpose of this class was to keep track of state which the
emulation core was already keeping track of. This is rather risky -
if we update the state of one of the two without updating the other,
the two become out of sync, leading to some rather confusing problems.
This duplicated state was removed from EmulationState in the
previous commits, so now there isn't much left in the class.
Might as well move its members directly into EmulationFragment.
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...
This enables scoped storage for new Dolphin installs on Android 11
and up (along with a few other changes in behavior which unlike
scoped storage are uncontroversial). Existing installs are unaffected.
We have to do this in order to be able to release updates on
Google Play from November 2021 and on.
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.
Special shoutout to Android for not having RTL compatible
variants of nextFocusRight and nextFocusLeft.
Ideally we would have some way to block the user from using
the d-pad to switch between the two panes when in portrait mode,
or make the list pane act as if it's to the left of the details
pane rather than the right when the details pane is open, but I
don't know of a good way to do this. SlidingPaneLayout doesn't
really seem to have been implemented with d-pad navigation in mind.
Thankfully, landscape is the most important use case for gamepads.
The way I'm implementing events using LiveData feels rather
unorthodox, but I'm not aware of anything in the Android framework
that would let me do it in a better way... One option I did
consider was wrapping the cheat lists in LiveData and observing
those, but then CheatsAdapter wouldn't know which cheat had
changed, only that there was some kind of change to the list,
necessitating the use of the not recommended notifyDataSetChanged.
This path isn't really any faster in the normal case,
but it does let us skip waiting for the lock to be available,
which makes a huge difference if the lock is already taken.
It seems like we spend a lot of the game list scanning time in
updateAdditionalMetadata, which I suppose makes sense considering
how many different files that function attempts to open.
With the addition of just one little atomic operation, we can make
it safe to call updateAdditionalMetadata without holding a lock.
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.
This partially reverts commit cbc4989095
due to a crash: https://bugs.dolphin-emu.org/issues/12561
I can't debug what the cause of the crash is due to not having an
Android TV device. Let's just revert this for now to fix the crash.
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.
Now that DOL and ELF files are assigned game IDs, all games have
game IDs. (Unless you intentionally craft an ISO file that has
the first bytes set to null, but if you do that I think you can
live with Dolphin creating a file in GameSettings called ".ini")
Back when I wrote this code, I believe I set it to use a custom path
so that the cache would end up in a directory which Android considers
to be a cache directory. But nowadays the directory which Dolphin's
C++ code considers to be the cache directory is such a directory,
so there's no longer any reason to override the default path.
progressMessage can have the invalid value of 0. That
progressMessage was being used for the thread name was
a typo anyway – it's supposed to use progressTitle.
This reduces the build time for incremental builds from about
2 minutes to about 20 seconds. Most people never run the
unit tests on Android anyway (I'm not aware of anyone other
than me ever having done it).
Any local references get cleaned up when returning to the JVM,
but some of the functions in AndroidCommon return to C++ rather
than the JVM, and functions with loops risk running into the
limit of how many simultaneous local references are allowed.
I was going to rename this to getSysDirectory to make it clearer
what the returned path actually is, but it turns out we're not
actually using this for anything anymore.
The Java implementation of getting the list of post-processing
shaders only looked in the Sys folder and not the User folder.
This could be fixed in the Java implementation, but it's
simpler to just call the C++ implementation instead.
Center @2x and android banners, and adjust @1x banner to improve
consistency with other resolutions while maintaining sharpness.
Images created by MayImilae
In 5a1a642, I explicitly set android:debuggable="true" for Dolphin.
(By default, it's set for debug builds but not release builds.)
The reason I made the change is because debuggable must be set to
true in order to allow adb backup to be used with apps which target
Android 12. We have no reason to want to stop users from debugging
Dolphin and certainly no reason to stop users from using adb backup
(especially not after forced storage is going to force us to store
the User folder in app-specific external storage!), but,
it turns out that setting debuggable to true is forbidden by
Google Play "for security reasons". Go figure. The beta build
which was tagged earlier today was rejected because of this.
I think the AArch64 JIT has come far enough that it doesn't have to
be called experimental anymore.
I'm also labeling the x86-64 JIT as x86-64 for consistence with the
AArch64 JIT. This will especially be helpful if we start supporting
AArch64 on macOS, as AArch64 macOS can run both the x86-64 JIT and
the AArch64 JIT depending on whether you enable Rosetta 2.
We don't actually need to do this until we bump targetSdkVersion
to Android 12 (which we can't do yet since we're not compatible
with scoped storage), but I figured I'd get it out of the way early.
Not tested on Android 12, but tested to not break stuff on Android 10.
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.
GameFileCacheService.startRescan (in MainPresenter.onResume)
does nothing if called before GameFileCacheService.startLoad.
Fixes a 3f71c36 regression where already added games would not
show up after app launch under specific circumstances.
Unfortunately the loading indicator still doesn't show up
during a rescan initiated by app launch, but that would
be more annoying to fix, so I will leave it for now.
We want to save the currently selected platform tab,
but doing so immediately after switching tabs leads to
unnecessarily much file I/O (on the main thread, no less).
This change makes us defer the saving until later.
In master, the game scanning process looks like this:
1. Scan for games
2. Scan for additional metadata (icon.png and meta.xml)
3. Save the cache if needed
4. Update the game list with the results
This change makes the game scanning process look like this:
1. Scan for games
2. Update the game list with the results
3. Scan for additional metadata (icon.png and meta.xml)
4. Update the game list with the results
5. Save the cache if needed
Updating the game list as soon as possible means the user
has to wait less before their games show up. The new behavior
matches what DolphinWX did before it was removed. (DolphinQt
has an even fancier approach where games get added one by one.)
The main reason why I'm adding this isn't actually to allow
users to swipe down to refresh, it's to add a loading indicator.
Considering that the Storage Access Framework can be slow for
folders with many items (many subfolders?), not showing a
loading indicator might give users the impression that adding
a folder resulted in nothing happening even though Dolphin is
scanning for games in the background. But I suppose letting
users swipe down to refresh is a nice bonus with the change.
EmulationActivity has an instance of Settings. If you go to
SettingsActivity from EmulationActivity and change some settings,
the changes get saved to disk, but EmulationActivity's Settings
instance still contains the old settings in its map of all
settings (assuming the EmulationActivity was not killed by the
system to save memory). Then, once you're done playing your
game and exit EmulationActivity, EmulationActivity calls
Settings.saveSettings. This call to saveSettings first overwrites
the entire INI file with its map of all settings (which is
outdated) in order to save any legacy settings that have changed
(which they haven't, since the GUI doesn't let you change legacy
settings while a game is running). Then, it asks the new config
system to write the most up-to-date values available for non-legacy
settings, which should make all the settings be up-to-date again.
The problem here is that the new config system would skip writing
to disk if no settings changes had been made since the last time
we asked it to write to disk (i.e. since SettingsActivity exited).
NB: Calling Settings.loadSettings in EmulationActivity.onResume
is not a working solution. I assume this is because
SettingsActivity saves its settings in onStop and not onPause.
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.
I moved it from the main settings screen to the in-game menu
in PR 8439 so that it could be changed while a game is running,
but now that the main settings can be accessed while a game is
running, there's no reason to not put it in the main settings.
https://bugs.dolphin-emu.org/issues/12067
This is already handled by SurfaceDestroyed. In the worst case,
the extra code could even race with SurfaceDestroyed if they
are triggered at the same time, but this is highly improbable.
Time for yet another new iteration of working around the
"surface destruction during boot" problem...
This time, the strategy is to use a mutex in MainAndroid.cpp.
JosJuice