Normally, Dolphin APKs have a lib folder that contains two subfolders:
arm64-v8a and x86_64. Both contain a libmain.so file, and arm64-v8a also
contains additional .so files for libadrenotools.
When we added netplay support for Android, we brought in Jetpack Compose
as a dependency, which in turn made libandroidx.graphics.path.so be
included in Dolphin APKs. Unfortunately, this .so file was included not
only for arm64-v8a and x86_64, but also for armeabi-v7a and x86. This
made Dolphin installable on devices that use one of these older ABIs,
but because libmain.so is missing, trying to start Dolphin on such a
device results in an instant crash. We have gotten a number of Google
Play reviews from armeabi-v7a users complaining about this crash.
This fixes the problem by setting abiFilters under ndk instead of under
cmake, as documented at https://developer.android.com/ndk/guides/abis.
Some poorly coded games are able to overflow some statistics (e.g. Jimmy Neutron: Boy Genius's title screen).
While funny, signed integer overflow is undefined behavior, and while in practice here it's extremely unlikely to cause issues, it's still better to avoid it.
When calling CreateDirectory for /wfs, we were passing a UID of 19,
because that is the UID /wfs is supposed to have. However,
CreateDirectory returns AccessDenied if we try to create a directory in
the root using a UID other than 0.
To fix this, let's use UID 0 to create the directory, and then change
the UID and GID afterwards using SetMetadata. This is what the ESCore
constructor does, which is the piece of code that normally creates /wfs.
When TASing, we savestate not just /tmp but also /. The code that was
added in d35fe1b didn't handle recreating / correctly.
This commit fixes the problem by skipping recreating /, which is fine
since it always exists.
This is a correction for 0cab1731d6 (part of #14665), where it was
overlooked that the condition to enable the RAM override was flawed: if
the user had enabled the emulated memory size override in Dolphin, but
the running game did not define a simulated memory size greater than the
retail memory size, the RAM override in IOS was wrongly misconfigured,
causing issues with Wii games.
Test plan:
- Launch Dolphin.
- In the **Settings > Advanced** section, tick the **Enable Emulated
Memory Size Override** check box, and set the maximum memory size for
both **MEM1** and **MEM2** (i.e. 64 MiB and 128 MiB respectively).
- Play any Wii game (e.g. _Mario Kart Wii_ (RMCE01)).
**Without** the patch, the emulator will hit an invalid read from
`0x83FEE78C` at `0x8019FE6C`:
<img alt="Invalid read when starting Wii game after having enabled the emulated memory override in Dolphin" title="Invalid read when starting Wii game after having enabled the emulated memory override in Dolphin" src="https://github.com/user-attachments/assets/1777485e-a421-4303-8d3d-dd49f1aaa9bf" />
**With** the patch, the emulator can execute the game as usual.
For some reason, #14738 removed the headers and allowed return codes which broke using the Netplay index for users.
Also, bools converted to a string using std::to_string would become 0/1, while fmt::format by default turns them into false/true, which also broke the index.
This reverts commit e4349ae179.
The 0x prefix is included in the characters count (unlike e.g. in Rust
where there is no 0x prefix), so that commit was wrong. Sorry about
that!
Fixes regression introduced in #14842.
Dolphin would previously crash while accessing &buffer[got], as if we
were trying to access that element instead of just obtaining a pointer
to it. The proper solution is to obtain a pointer to the first element,
and only add the offset we want to get the range.
Here is the printed message:
/usr/include/c++/16/array:210: constexpr std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator[](size_type) [with _Tp = char; long unsigned int _Nm = 128; reference = char&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
The stack trace originates from:
Source/Core/Core/HW/EXI/EXI_DeviceGecko.cpp:139
Large anonymous mappings are split into 128 MB chunks. Without MAP_MEM_VM_SHARE,
mach_make_memory_entry_64 will only return an entry spanning the first chunk.
Attempting to map through that entry will fail if it extends beyond the 128 MB
boundary, which can happen when the sizes of MEM1/MEM2 are overridden.
JosJuice