0x0ade/fnadroid-legacy

Unofficial "FNA for Android" wrapper.

FNADroid

Unofficial "FNA for Android" wrapper.

Ever wanted to publish an Android version of your FNA game? Never wanted to use MonoGame or pay weird fees just to get it running? Then FNADroid is.. well, still in its early phase, but maybe suited for you!

• Uses a custom compiled Mono (".NET for Linux") runtime, staying up-to-date and performant.
• Supports only 99% of Android devices; who uses ARMv5 nowdays?
• Out-of-the-box only supports only 67.8% (Android 4.3+) devices due to possible future GLESv3 code & device performance (it's possible that the minimum API will be lowered in the future).
• Tries to work with mainline FNA.
• Only compiles on Linux.
• Uses GLESv2, possibly killing your game.

fnadroid-legacy's Issues

DRM issues

It's currently impossible to check whether the game has been bought in the Play Store (license check), nor rely on Android's safer storage of the app. One could try to call the Play Store API through the JNI via C# with externs and __Internal, but even writing that was quite complicated.

Implement Guide.BeginShowKeyboardInput or similar

It's currently hard (not impossible) for games to actually call the keyboard. XNA offers Guide.BeginShowKeyboardInput and Guide.EndShowKeyboardInput, but both are part of the GamerServices namespace... which is part of MonoGame.Net.

Either FNADroid will ship with an MonoGame.Net implementation for Android (highly improbable as I haven't got access to the "Google Play Developer Console" and thus can't test anything related to the "Google Play Games Services"), or FNADroid will offer an alternative, just as with the vibration implementation.

Guide.BeginShowKeyboardInput: https://msdn.microsoft.com/en-us/library/bb975190(v=xnagamestudio.42).aspx

Implement Windows Phone - esque tombstoning

Android games need to handle the context switch (if any) that occurs when pausing and continuing the app. Windows Phone handles multitasking differently.

On WP, the app lifecycle contains the "Deactivated" and "Activated" events. When deactivated, the app stays in the "Dormant" state, effectively freezing the app. If it isn't in the "Dormant" state, it will be "Tombstoned", thus killed. All state-saving-keeping-magic on tombstoning should happen in the game itself.

The "Dormant" state will be harder to implement without support for GL context switches in the game (they don't seem to be part of WP).

"Activated" and "Decativated" in WP map to "onResume" and "onPause" in Android. They should map to the Game.Activated and Game.Deactivated events in XNA, but unfortunately just by listening to them it isn't clear if the game starts and ends or if the game resumes and pauses.

To differentiate between the state during Activated and Deactivated, games supporting tombstoning (should) use Microsoft.Phone.Shell.PhoneApplicationService.

Sidenote: With the current Android-SDL2-Mono-FNA brew, Mono automatically dies as soon as the app is paused (or something goes horribly wrong in SDL2 / FNA and Mono can't handle it... whatever happens, it shouldn't). It normally is a bug, but as long as the death is delayable / managed code is still runnable, it is abusable as function.

(Mono doesn't crash on pause anymore; GL-context-less Dormant is now implementable.)

• Reimplement PhoneApplicationService or offer an alternative via FNADroid class
• Trigger Activated and Deactivated events in Game on resume and pause

Windows Phone app lifecycle: https://msdn.microsoft.com/library/windows/apps/ff817008(v=vs.105).aspx
Android app lifecycle: http://developer.android.com/training/basics/activity-lifecycle/pausing.html
"Windows Phone Mango - Tombstoning XNA": https://fiercedesign.wordpress.com/2011/08/29/windows-phone-mango-tombstoning-xna/

FNA fails loading entry points

Simply said, FNA can't find all entry points. I can only guess that some functions simply don't exist or exist with another name (example: glDepthRange on GL vs glDepthRangef on GLES; glPolygonMode missing).

Automatically use device vibration and offer other controller helpers

Every Android phone (unfortunately not many tablets) and some controllers (not my OUYA controller) offer vibration. I haven't tested the controller vibration yet, but as SDL2 automatically picks up the accelerometer as controller (FEZ is technically "playable" without controller out of the box to some degree), it should also be possible to hook the controller vibration to make the phone vibrate, either via FNA or SDL2 itself.

Map back button to GamePad.GetState(PlayerIndex.One).Buttons.Back

FNADroid already disables Android's "exit on back button press". The XNA Windows Phone sample project contains following code:

// Allows the game to exit
if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
    this.Exit();

FNADroid should thus map the back button of the controller of player 1 to the back button of the phone.

A problem that could arise is the conflict between the phone back button and the back button of the controller connected, if any. Ideally, both trigger a press, while a release only occurs if both are released.

Controller interference is also a problem that arises if handling vibration and accelerometer data through the controller: https://github.com/0x0ade/FNADroid/issues/4#issuecomment-192903143

FEZ (possibly other games) accessing inaccessible paths

Some games try to access paths that normally are not accessible. Such a path is f.e. /data/.config with FEZ, as /data is Android's HOME environment variable. Only problem with it is that the /data partition is well secured and thus /data/.config is inaccessible.

To be fixed via a patch in Mono or by manually setting the HOME environment variable.

Unclear where to store game / mono

Currently the game data is stored at /sdcard/Android/data/com.angelde.fnadroid/game with mono being similarly placed at /sdcard/Android/data/com.angelde.fnadroid/mono. Games shipped with FNADroid would need to extract their game data and mono from the APK manually, which seems like a waste of space and a problem because of the Play Store's APK size limitation.

TODO: Find out how obbs work / deliver "game data" via Play Store and possibly use them