Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

[Closed] Some points about AndroidPluginLanguage

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.

Product Version: Not Selected
more ▼

asked May 26 '16 at 05:15 PM in Packaging & Deployment

avatar image

Answers.Archive STAFF
1.9k 209 316 690

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

The question has been closed May 26 '16 at 05:16 PM by AndrewHurley for the following reason:

The question is answered, right answer was accepted

1 answer: sort voted first

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.


more ▼

answered May 26 '16 at 05:15 PM

avatar image

Answers.Archive STAFF
1.9k 209 316 690

avatar image Answers.Archive STAFF May 26 '16 at 05:15 PM

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 }.

avatar image Answers.Archive STAFF May 26 '16 at 05:15 PM

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.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question