If you already have a mapping set in the advanced mapping dialog and
want to change it, the easiest way to do it is to press Clear and then
select the new mapping from the list. But pressing Clear causes the
dialog to close, forcing you to open it again, which is inconvenient.
This commit makes it so the Clear button doesn't close the dialog.
Probably a copy-paste error from layout-ldrtl/list_item_setting.xml.
This error made it so a long setting name could overlap with the
checkbox next to it if Dolphin was running with right-to-left layout.
The incorrect ID was apparently also causing the app:lintVitalRelease
build task to fail. I guess we're not running that build task, because I
only heard of this from someone building Dolphin locally.
There's no guarantee that directory initialization has completed by this
point, so we can't safely use NativeLibrary.
I'm making this change because of a crash being reported in Google Play
Console. The exact way it's crashing is mysterious to me, so I'm not
sure if this commit fixes the crash, but I think this commit is
a reasonable change to make even if it doesn't fix the crash. Backtrace
from Google Play Console:
#00 pc 0x0000000000469074 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (std::__ndk1::pair<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>::pair[abi:nn180000]<char const* const&, char const* const&, 0>(char const* const&, char const* const&)) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#01 pc 0x0000000000468e9c /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (std::__ndk1::pair<std::__ndk1::__tree_iterator<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::__tree_node<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, void*>*, long>, bool> std::__ndk1::__tree<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::__map_value_compare<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::less<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, true>, std::__ndk1::allocator<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>>>::__emplace_unique_impl<char const* const&, char const* const&>(char const* const&, char const* const&)) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#02 pc 0x0000000000462f08 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (Common::Log::LogManager::GetLogTypes()) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#03 pc 0x000000000044339c /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (Java_org_dolphinemu_dolphinemu_NativeLibrary_GetLogTypeNames+56) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#04 pc 0x000000000031456c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+108)
#05 pc 0x0000000000781508 /apex/com.android.art/lib64/libart.so (nterp_helper+152)
#06 pc 0x00000000002d94d4 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/base.apk (org.dolphinemu.dolphinemu.features.settings.ui.SettingsFragmentPresenter.<clinit>+16)
[...]
a1691a4 made it so analytics start events can only be generated when
starting the main activity. However, some users launch Dolphin's
emulation activity from a separate frontend application, bypassing
Dolphin's main activity. This change adjusts the logic so that start
events can be generated if any activity is started after 6 hours of
inactivity. This more closely matches the behavior we had before
a1691a4, while still ensuring duplicate start events aren't generated.
I've also fixed the inconsistent indentation in ActivityTracker.kt.
71f654c added a new platform in the middle of the C++ platform enum
without updating the corresponding Android code, making the Android code
incorrectly treat Wii discs as WAD files, WAD files as DOL/ELF files,
and so on. This commit fixes the problem.
To be able to add the new Triforce entry into the Platform enum without
it leading to the UI getting an additional tab, I'm splitting the enum
into Platform and PlatformTab. Platform now exactly matches the C++
enum (previously it excluded ELFOrDOL), and PlatformTab has the same
content as the old Platform.
dolphin-start event was being generated twice for the normal
end-user case, as can be seen in analytics data for some years.
The problem occured when:
* Android reaped the process hosting the dolphin activity
(e.g. for power/memory saving).
and
* Dolphin activity was in "stopped" state for > 6 hours before
being switched back to.
Under above conditions, both calls to ReportStartToAnalytics
would be performed, as dolphin thought it was being launched anew,
and also thought it had been asleep for > 6 hours.
fixes https://bugs.dolphin-emu.org/issues/13675
This is an Android continuation of bc95c00. We now call
InputDetector::Update immediately after receiving an input event from
Android instead of periodically calling it in a sleep loop. This
improves detection of very short inputs, which are especially likely to
occur for volume buttons on phones (or at least on my phone) if you
don't intentionally keep them held down.
Instead of having UserDataImportWarningDialog set an
`onResultDismiss` callback that examines `mustRestartApp`, and having
UserDataActivity set `mustRestartApp`, just have UserDataActivity set
the callback directly.
This approach is no more data-race-y than the previous approach, and it
simplifies the code. (The behavior of restarting the app when the task
finishes is specific to the user data import flow, and there is no
reason for TaskViewModel to be directly aware of it.)
JosJuice
JMC47andGitHub
TilkaandGitHub
Zopolis4
Shawn Hoffman
Sam Belliveau
Jordan Woyak
Niel Lebeck
Daniel Peukert
Admiral H. CurtissandGitHub
Gamer64
Dentomologist