Some points about AndroidPluginLanguage

Development Pipeline & Plugins Plugins
, , , , ,
1

I’ve just stumbled upon the AndroidPluginLanguage (APL) format, which is a exactly what we need for our FMOD audio integration on Android.

A few points:

1.) Any reason all the flow control is expressed in an xml file format? UBT is in C# and the build modules are dynamically compiled C# files, so it that seems like an simpler way to do it.

2.) The format is very clearly documented in AndroidPluginLanguage.cs which is great. Publishing it online would give it even greater visibility. Searching for AndroidPluginLanguage via UDN finds only a single one line revision entry.

3.) The documentation has two typos in the architecture list: “armeabi-armv7” should be “armeabi-armv7a”, and “armeabi-armv8” should be “arm64-v8a”.

4.) Is there any way to access the target configuration from the APL file? We link against a logging .so for normal builds, and a release .so for UE4 shipping builds. Current workaround is to have two copies of the APL, and reference the appropriate one from the .build.cs file.

5.) The APL knows the architecture, but is there any way to access it in the build.cs file? The closest I could find is OculusMobile.build.cs which hard-codes armeabi-v7a, and coremod.Build.cs which just lists all architecture directories.

2

Hi Geoff,

Yes, APL is the way to deal with any customization for plugins for Android. Addressing your points:

  1. We wanted something which wouldn’t require any compiling for any platform.
  2. There is a task to properly document it; the best documentation at this point is the comment block I wrote at the top of the source file as you discovered. It was mentioned in the release notes for 4.10.
  3. Oops, you are correct. I have fixed this for next 4.12 preview.
  4. You can use < isDistribution /> flow control or $B(Distribution) variable. I use this in the GearVR_APL.xml for the Gear VR plugin in Engine/Plugins/Runtime.
  5. This is one of the reasons I needed to write APL. It is not possible to check the architecture in build.cs due to the fact the target platform is Android and there is no knowledge of which architectures were enabled to build (we loop through any configuration of architecture + GPU enabled). What we do to deal with architecture differences from the build.cs is filter the include and library paths. You may notice we add all the architectures into PublicIncludePaths and PublicLibraryPaths for Android in libcurl.Build.cs. When we compile the source for ARMv7, for example, we remove the include and library paths that contain the other architectures in the string.

Let me know if you need any more help.

Chris

3

Thanks, very useful. Regarding 4 though, I assumed Distribution would be whether the user is packaging a stand-alone build or not. I’m after what the configuration is, one of { Debug, Development, Shipping, Test }.

4

A distribution build will be signed for the store, and unless done from the command line will always be a shipping build (distribution checkbox forces Shipping in the editor) and non-distribution will be Development. APL does not expose the configuration at the moment so if you really need to check for Test, for example, registering a different APL file in the build.cs is probably the best way to do this.