Home/ Questions/Q 6216603
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T07:16:39+00:00

I’m porting a native C++ engine to Android NDK. After trying some environments and

  • 0

I’m porting a native C++ engine to Android NDK.
After trying some environments and tools, I found the latest vs-android (0.9) to be the most comfortable.
I do have a few problems with it (some I may need to ask in future questions), but for now – here’s one:

The native engine compiles to a native shared library. We want the engine to be android-8 API compatible (android 2.2).

We have a few tester applications we use internally. I’ve ported one of them to Android as well, but since I’m using native activity (and native app glue on top of that), it requires android-9 (2.3).

I have some module projects – static libraries – which are used in both the engine and the tester app. I need these to compile to android-8 for the engine, and to android-9 for the tester.
In addition to all of that, we want to support both arm5 and arm7.

With the ndk build scripts I can do this fairly easily. In MS-Build (which vs-android uses) it seems to require an exponential number of configurations (don’t forget about debug/profile/release).

Is there a way to do this without creating all these configurations? Such that when I build my engine, for example, it will compile the modules for android-8, and for both arm5 and arm7, and when I build the tester it will compile the modules for android-9 and for arm5 and arm7, without creating 4 almost identical configurations for each project and for debug,profile,release?

I found this, but I’m not sure how to use it and if it’s possible to apply the technique of parent/child projects here.

(Telling me to ‘stop being lazy and just create the configurations, despite the fact that whenever you want to change the parameter you’ll have to change it in all configurations’ is acceptable as a comment, but please – not as an answer. Same goes for ‘use ndk-build and manually build your apk instead of using vs-android’).

Thanks!

(BTW, can someone please add a vs-android tag?)

EDIT:
I came up with a partial solution – only to the API level issue. See my answer below.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    OK, here’s a partial solution I’ve found (since no one else has come up with another answer).

    This is regarding the API level issue. It will also work for anything that is solution-specific.
    Specifically for my problem –
    For each project (all the static libs, the engine shared lib and the tester shared lib), I added the following to the project file:

      <Import Condition="Exists('$(SolutionDir)AndroidSolution.props')" Project="$(SolutionDir)AndroidSolution.props" />

    And then, each solution can determine the parameters it needs for all of its projects by adding a file called ‘AndroidSolution.props’ to the same folder as the solution file.
    A sample props file:

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <AndroidAPILevel>android-8</AndroidAPILevel>
    <!-- <AndroidArch>armv7-a</AndroidArch> -->
  </PropertyGroup>
</Project>

    That way the API level is determined for all the projects in the solution, and they can change for different solutions.

    As for the multiple ABI’s, I added the following to the XML:

    <AndroidArch>__ANDROID_ARCHITECTURE__</AndroidArch>
<PlatformToolset>__PLATFORM_TOOLSET__</PlatformToolset>

    And used a short script (which is called multiple times before each msbuild execution) to replace both parameters in the build script

    • 0