Even after updating the androidx window library, this did not fix the issue for all devices. This ensures that the measured size of the overlay will be used instead of a potentially larger one seen by androidx.
Previously the emulation surface wasn't being updated during configuration changes and only during specific view events. This would break input and the screen dimensions after each orientation/aspect ratio change. Now a new surface is provided every time and the display dimensions are updated as needed.
Before this would run on the main thread and freeze the device. Additionally this fixes the result dialog not appearing if a config change happens during the installation by getting the activity's fragment manager when needed.
Emulation states are repeatedly checked by input and performance stats. During startup and shutdown, this could lead to a long halt on the UI thread because the call to IsRunning will be waiting on the emulation mutex to be unlocked. Using atomics should replace the existing functionality without causing problems.
All dialog code (except for the Date/Time ones) has been extracted out into a generic settings dialog fragment that handles everything through a viewmodel. State for each dialog will now be retained and dialogs will stay shown through configuration changes.
I won't be changing the current state of the date and time dialog fragments until Google decides to make their classes non-final or if/when we migrate to Jetpack Compose.
If something like a lifecycle event happens when this switch is toggled (Ex. whenever the black backgrounds switch is toggled), this could move the switch from the default position and trigger the checked changed listener and restart the loop. Here I just removed the listener at the start so we recycle the view properly still, set the checked state and then add the new listener.
Consolidates all of the settings components to the fragment and activity with no interfaces and only the settings fragment presenter. This also includes new material animations and new viewmodel usage to prevent the fragment and activity directly interacting with one another.
Take advantage of the new settings interface to reduce the amount of code we need for each setting item. Additionally make all settings items non-null to improve brevity.
Completely removes code related to parsing the settings file on the java side. Now all settings are accessed via NativeConfig.kt and config.cpp has been modified to be closer to the core counterpart. Since the core currently uses QSettings, we can't remove reliance from Wini yet. This also includes simplifications to each settings interface to get closer to native code and prepare for per-game settings.
Previously the emulation surface wouldn't respond properly to orientation changes. This would result in the screen appearing stretched when starting in one orientation and switching to another.
The code for calculating the bounds of the view have been changed to match the expected behavior now. Before the view would just match parent in height and width. Now instead of using setLeftTopRightBottom (which is intended to be used for animations) we pass newly calculated bounds for the view into super. Now the view bounds match the emulation output.
This also means that we don't need the overload for the SettingsActivity to launch it using an ActivityResultLauncher. We can just update the view in onResume.
There's a bug in ktlint where it will run into an error if you build the project, delete a source file, and then build again. It will be unable to find the file you deleted and can't recover until these files are deleted. This just deletes those files before every run.
Allow for displaying options in the home options that are disabled with messages that explain why they are disabled.
This includes reasoning for the GPU driver installation button.
While this can be convenient in some scenarios, this will be a big problem for users trying to sideload different APK versions. If they forget the last one they had installed, they could have problems installing a new copy.
Now within the Input Overlay file, there is a version that will determine when the overlay will be reset. This is intended for breaking changes like the ones we had with the additions of percentage based layouts or the addition of foldable/portrait layouts. This also includes versions for each individual layout so we don't have to reset every layout if only one is broken.
Additionally, this includes new L3/R3 buttons.
