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.
This assumption is false both in portrait mode (where it only
covers the top half of the screen) and when using two apps at once.
Fixes https://bugs.dolphin-emu.org/issues/12307.
This was removed in cc5802b when it should have
been converted to the new setting instead,
and it seems like I didn't notice when reviewing it.
I'm changing the DirectoryInitialization logic a little
so that clearWiimoteNewIniLinkedPreferences also is called
when there was no WiimoteNew.ini previously, in case the
user deleted WiimoteNew.ini but not Dolphin.ini.
We generally have no reason to call these functions on our own, so
there's not much reason to declare them, especially not in the cpp
file where they're defined. In case we ever do get a reason to do
it, we can add declarations for just the functions that need them.
In case someone wants to be very careful with how much bandwidth
they use or with what data GameTDB.com collects on you.
This is already an option in DolphinQt (though in DolphinQt it
will switch entirely from using covers to banners when turned off).
It would be difficult to use the AlertMessage class for
messages that need to be showed outside of emulation,
but showing them as toasts is better than not showing them.
During emulation, when LocalGame has a value but CurrentRun
doesn't, we want to read from LocalGame, not CurrentRun. This
change exposes a LAYER_ACTIVE option that handles this correctly.
This is part of my efforts to add support for scoped storage.
I figured I would start with a relatively simple feature to
make sure that everyone is fine with the approach I'm taking
before I tackle more complicated features like the game list.
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.
The only place where initTouchPointer was called automatically
was Host_RequestRenderWindowSize, which is called at least once
after emulation start, but not after activity recreation.
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.
Except controller settings, because those would be annoying
to fit into the same system, and I only need the non-controller
settings to be brought over for the next commits to work.
...instead of waiting for it after launching EmulationActivity.
We need this because there is code that runs very early in
EmulationActivity that accesses the settings.
Android TV devices aren't the only devices without touchscreens.
Regarding MotionAlertDialog, I could've replaced the leanback
check with a touchscreen check instead of just removing it,
but I thought there was no reason to prevent people with
touchscreens from doing a long back press if they want to.
https://bugs.dolphin-emu.org/issues/12029
We currently have one way of opening the menu on touch screen
devices (swiping down from the top of the screen to bring up the
action bar and selecting the menu in the action bar), and another
way of opening the menu on Android TV (pressing Back). However,
some devices that claim to support touch (or don't support
leanback? Dolphin currently conflates the two) don't actually let
you swipe down from the top of the screen in the way that Dolphin
expects, notably Chromebooks. There are also some phones where you
can swipe down from the top of the screen but this for some reason
doesn't lead to the action bar becoming visible, though we are
getting less reports about this nowadays than in the past.
This change makes us use the Back method on all devices,
since it should work on all devices with no significant drawbacks.
Unfortunately, we not only have two different ways of triggering
the menu but actually two entirely different menus, with the
non-touch menu not implementing options that only are revelant
when using a touch screen. A later commit will add the missing
features to the menu that we now use on all devices.
The reason why the finish() call was added no longer exists.
(Also, there was never a duplicate SettingsActivity as far as
I can tell, only a duplicate SettingsFragment.)
Just for maintainability. This is a shorter and more standard
solution compared to our current one where the Fragment
persists the Settings and passes it to the Activity.
That a device doesn't have a touchscreen doesn't necessarily mean
that it doesn't support rumble (though it is usually the case).
setPhoneVibrator already contains a check for whether the device
supports rumble, so we can simply remove the touchscreen check.
