

sharpdroid
this is an android app that runs SharpEmu, a PS5 emulator for Windows and Linux on x86-64. sharpdroid focuses on low overhead, mergeability, and modularity.
Cost / License
- Free
- Open Source (GPL-2.0)
Platforms
- Android
Features
- Playstation
sharpdroid News & Activities
Recent activities
- justarandom added sharpdroid
justarandom added sharpdroid as alternative to KytyPS5, RPCSX, KyTy and prosper (PS5)
sharpdroid information
What is sharpdroid?
this is an android app that runs SharpEmu, a PS5 emulator for Windows and Linux on x86-64. sharpdroid focuses on low overhead, mergeability, and modularity.
requirements
an arm64-v8a processor, android 9 or later, and a GPU with vulkan support. thats it. how it works
tl;dr: sharpdroid ships a compatibility layer purpose-built to run SharpEmu's x64 Linux build on arm64 android.
sharpdroid +-- user interface +-- host layer +-- ELF loader +-- syscall dispatch +-- thunk dispatch ¦ +-- vulkan and aaudio +-- signal delegation +-- VMA and SMC tracking +-- FEXCore ------------x86-64-below------------ +-- SharpEmu (linux-x64) +-- the PS5 game
SharpEmu has no CPU emulator. instead, it executes x86-64 PS5 guest code natively on an x86-64 host CPU. there is simply nothing there, to port to arm64 android.
thats where FEX comes in. we use the x86-64 to arm64 translator it ships, FEXCore, to read x86-64 and emit arm64, as SharpEmu runs.
on arm64 Linux, which is FEX's intended usage environment, FEX also ships what it calls its frontend; a Linux program that loads the guest, answers its syscalls, and delivers its signals. FEX's frontend is a program. we need a library. which is why we implement an analogue that works as such: our host layer.
our host layer routes most of what SharpEmu asks for through to the Linux kernel at android's heart. files, memory, threads, and futexes are all answered by the real thing. though this does not work for all types of question; for instance, when SharpEmu asks which program it is, the host layer answers SharpEmu, instead of an android app, which is what the kernel would have said.
graphics and audio are solved without serialisation or copying, since guest and host share one address space.
a decoy libvulkan.so driver reroutes graphics API calls from SharpEmu to the host layer's vulkan thunk, and as a result of that to the system driver or a loaded mesa turnip driver, directly. each frame is drawn straight from SharpEmu into android's ANativeWindow.
similarly, a decoy libaaudio.so driver reroutes audio API calls from SharpEmu to the host layer's aaudio thunk. all audio is played straight from SharpEmu through android's AAudio.


