build(android): support android platform (config and logging)

[mengyanshou]

Description

Adapt config and logging for Android:

• Add macro definitions to ensure successful compilation.
• Add a custom Boost backend for Android to ensure proper functionality.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

[ReenigneArcher]

Thank you for the PR! I'm looking forward to this.

I expected more changes for in order for initial Android support. Is there more coming? Maybe something in the ./cmake directory?

[mengyanshou]

Sorry for the delayed response. Unfortunately, I don't have much time either.

My main tech stack is Flutter (UI Framework) and Android Native.

Typically, the compilation of an Android app differs significantly from C/C++ and requires the Java environment and Gradle.

So, from my current perspective, it seems quite difficult to make the Sunshine workflow directly produce an APK.

Additionally, I'm concerned that my lack of proficiency in C/C++ might disrupt the original workflow, so I plan to submit PRs in multiple stages.

However, I can start with some compilation adaptations to ensure that future Sunshine APKs for Android can be imported and compiled smoothly.

As seen in the patches, I can now directly use the Sunshine Source along with a Patch Script to make Android compilation work properly.

My initial idea is to submit these patches to Sunshine so that the Android-compiled Sunshine and the Sunshine source code can remain consistent.

Additionally, I’d like to share some recent comparisons with scrcpy.

I’ve studied a lot of scrcpy’s code. In fact, scrcpy is already very efficient. It’s possible that the client’s use of SDL2 results in rendering that’s not as extremely efficient (just a guess). However, in terms of the server side, scrcpy and the ported Sunshine for Android should be roughly the same.

That said, porting to Android still has significant value because it allows users to use Moonlight to stream their Android devices.

I will continue to push this process forward.

[FrogTheFrog]

Unless there are some compilation issues, I would not touch the display_device. This function

Sunshine/src/display_device.cpp

Line 615 in 5da5293

std::unique_ptr<SettingsManagerInterface> make_settings_manager([[maybe_unused]] const std::filesystem::path &persistence_filepath, [[maybe_unused]] const config::video_t &video_config) {

only creates a SettingsManager for Windows at the moment.

This means that every display_device function will either do nothing or act as a "pass-trough". Same for logging - nothing should be logged via setup_libdisplaydevice_logging, so maybe just keep it as it is?

[FrogTheFrog]

This whole section is not correct way to log to android via boost. You need to create a custom sink (like here https://gist.github.com/cawka/ca21d79605bf51621d6206d2cd76b638) and then probably replace the default sink (

Sunshine/src/logging.cpp

Line 110 in 5da5293

sink = boost::make_shared<text_sink>();

) with your android one.

[mengyanshou]

Ok, I will try to modify this part, but it will be a little later. Thank you for your review

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 New issue
1 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[ReenigneArcher]

Does it compile if you remove the ifndef?