1) What is the total file size of the game assets? (file size of the Compiled/Data folder)2) Are you using the OBB file that the plugin builds, or are you building the OBB file yourself?3) Are you trying to embed the OBB file into the APK (e.g., RSA public key is blank), or load it from external storage (RSA public key is filled in)?3a) If loading the OBB from external storage, are you certain that you've placed the OBB file in the correct location?4) Do both of the console windows that pop-up during the Android build process show that their respective processes were successful?

Maybe try enabling log in the acsetup.cfg and see if there is something useful?Log is enabled as "log=1" under "[misc]" group.I am not sure where the log file will appear. When I tested Android port on emulator, it appeared in "ags" folder on sdcard, but since you are creating a standalone APK with your game, it may be written to game location, or somewhere else around (I do not know Android rules for this).

Also I think you need to clarify which version of AGS this Android creator plugin supports, and which version is your game made for.

Also I think you need to clarify which version of AGS this Android creator plugin supports

The AndroidBuilder plugin itself requires the AGS editor version 3.4.1 (has a dependency on #354), but it should be agnostic of the actual engine version. The plugin includes prebuilt native libraries from September 2016 (when the last plugin version was published), which were from the latest 3.4.1 dev branch at that time...

I was looking over the plugin source to try and figure out what might be the problem, and I think I've figured it out. Are you using AGS 3.4 to build the APK, or do you just mean that you took the demo game project from 3.4? Despite the 3.4.1 dependency, I don't see that the plugin would actually report an error if using an earlier version. I don't recall if the AGS version was actually updated to 3.4.1 at the time, but the plugin's "RequiredAGSVersion" attribute is set to 3.4.0, and the build process itself doesn't detect if the "Compiled/Data" directory doesn't exist. Therefore, I believe the problem is simply that you're using the wrong AGS version and the plugin isn't detecting that, so you're getting an empty OBB file.

The AndroidBuilder plugin was last updated in September 2016 and depends on features of AGS 3.4.1, however, the AGS version was not increased to 3.4.1 until October 2016, so the plugin (at the time it was last updated) did not have a way to detect the proper minimum AGS version. However, it could also be updated to have a formal dependency on the game data file itself (e.g., Compiled/Data/GameName.ags), which it currently doesn't have. I will push an update to the plugin, but please make sure you are using AGS 3.4.1 (or later, for you future readers!).

I do not know if that is safe to use AGS 3.4.1 engine (port) right away, because after the changes I made to OpenGL there is no guarantee it will work on mobile ports yet. This requires additional work to test and get it working.

For the instance, recently I added shaders for sprite tinting/light support in OpenGL, which was missing in earlier. For this I used a new group of functions, and I cannot even tell whether that will build and run properly on Android without including more headers or doing some modifications first.

Also, I do not build Android APK myself, and the build server has stopped working a while ago, because Nick Sonneveld did not have time to update it. So unless someone provides new APK, game built with 3.4.1 editor won't even run on Android. Games built with 3.4.0 even might have some issues if APK was made last September, because last 3.4.0 update happened in March this year.

To summ up, one would need a 3.4.1-compatible APK and OpenGL needs testing and fixing for mobile ports.

I think there may be some misunderstanding as to how the AndroidBuilder plugin is working. The APK it provides depends on prebuilt native libraries (including the engine, of course), and does not do anything in the way of pulling those libraries from the editor directory... That is, WindowsBuildTarget grabs acwin.exe and LinuxBuildTarget tries to pull the Linux native engine files from the editor directory, but the AndroidBuilder plugin does not. The plugin's native libraries are packaged inside of the "template.zip" which contains a template from which an Android Studio project is created. The native libraries are contained in the libs folder inside template.zip. The end-user may later replace the extracted native libraries in the "Compiled/Android/Studio/libs" folder, but that goes beyond the plugin's scope of control.

Further, the AndroidBuilder plugin does not use the "AGS game launcher" APK in any way, so that project is unrelated.

The native libraries that are currently packaged with the AndroidBuilder plugin are from September of last year, well before you started any work on OpenGL.

Finally, the AndroidBuilder plugin is experimental and is explicitly designated as not fit for regular production releases. However, it absolutely depends on the 3.4.1 editor to work properly.

That said, a future "stable" release of the plugin would expect to be able to read prebuilt native libraries from the editor directory, but the plugin is not that far developed yet.

Hm, so is it possible to run this plugin from 3.4.1 Editor to package a game compiled in 3.4.0 Editor without changing game data itself? If something like that could be done, then it might be a workaround for now.

3.4.1 and the plugin itself are both currently in "unstable" status. If something doesn't work properly then that isn't actually much of a surprise, is it? That's the whole reason for not calling it stable. And the status of the plugin itself isn't really the concern of the AGS dev team proper, but just myself (the sole author/maintainer of the plugin). Really, this thread doesn't even belong in this forum, and should probably be merged with the plugin's thread.

P.S. I do understand the concerns about basing work off of an unstable release of AGS, don't get me wrong, but the plugin itself is still considered to be in "alpha" stage. The whole process is still very messy and potentially error prone (e.g., creating an APK with no game files if wrong AGS version is used, no compile error if building OBB or APK fails, etc.). However, there are technical reasons why 3.4.1 is needed...

Add spoiler tag for "Technical reasons:":

The "OBB" (Opaque Binary Blob) file used by the APK is required to be formatted as a FAT16 virtual drive, into which the game files are mounted. This is done by a modified version of the Android SDK's "jobb" (Java OBB) tool. The jobb tool recurses an entire directory and adds its contents to the FAT partition that it creates, thus the game's data files being moved into the Compiled/Data folder was necessary to avoid further modifying the jobb tool. Which isn't to say that that's the only reason why the files are in the Compiled/Data subdirectory -- that change does make sense in its own right and should have been done from the start, an error on my part. I just mean that since 3.4.1 is the earliest version to have the data files built into its own directory, that is the lowest supported version the plugin can use.

Regarding the modifications to the jobb tool: The jobb tool distributed with the Android SDK is bugged in that it uses a FAT library's function to determine (from file size) which FAT partition type to use (incorrectly, I might add! It returns FAT32 for anything over 511 MB...) despite the fact that Android API's "mountObb" function requires a FAT16 partition type. The modified jobb tool that the plugin uses correctly selects a FAT16 partition type for anything under 2 GB, which is the upper limit of a FAT16 partition and also the upper limit on the expansion file (the OBB file) uploaded to the Google Play Store alongside an APK. Games over 2 GB would require an alternative approach to supplying the game assets to the end-user and cannot use the GPS expansion file.

Did you actually build 3.4.1 and test it on Android, or you're just saying things that you don't know what they mean? The plugin depends on editor features of 3.4.1, the actual build process does not. I've explained this to you before. However, since the build server is out of date and sonneveld has completely broken the ability to build the Android libraries from Windows, there's not really much that can be done in the way of building the native libraries.

No. That's not what I asked. The 3.4.1 release you installed does not include any Android port of the engine. The plugin does. The engine that the plugin contains is out-of-date. This leaves you with two options:

1) Rebuilding the Android port is currently only possible from Linux AFAICT. The 3.4.1 branch is unstable and the Android port may not run (this has not been confirmed). If you rebuild the 3.4.1 Android port, you may encounter issues which already exist in 3.4.0, or you may encounter entirely new issues.2) The custom 3.4.0 editor is not the same as the current 3.4.0 release (patch 4), and the two are not compatible. The custom editor is out-of-date with the 3.4.0 patch 4 release, and contains source code modifications which have been adopted into 3.4.1 (some, not all of the source code changes of 3.4.1). The Android engine port the plugin contains is from the same out-of-date version of 3.4.0, and may not be compatible with 3.4.0 patch 4. Additionally, the plugin itself is unstable, which means there may be unknown/unforeseen issues.

What you have is an APK with a game data file reporting AGS version 3.4.1 and an engine reporting AGS version 3.4.0. The engine is not able to load the game data file, which is why you get only a black screen. The error is not properly detected by the plugin nor the Android engine port (or, in the case of the latter, is not reported to the user). Even if the 3.4.0 patch 4 Android port were rebuilt, the plugin still depends on those changes from 3.4.1.

The plugin depends on the jobb tool, which recurses a directory and adds its entire contents to the OBB file. This tool cannot simply be given a list of files to add without major changes to the source of the tool, they must reside in their own, separate directory (e.g., "Compiled/Data" and not "Compiled"). Therefore there is no simple way to solve this problem at the present time. You must either use a custom build of the editor, or else you must rebuild the 3.4.1 Android port. I do not have any plans to fix the plugin to work with 3.4.0, for the reasons described here. I am actively working to try and rebuild the 3.4.1 Android port, and that is the approach that I suggest be taken moving forward, despite 3.4.1's current unstable status.

I can honestly say that I also did not understand the meaning of your question until now. Even though I know the situation about various version differences, but most people around here do not know such details (and probably should not). I think explaining these only makes them more confused.

I believe that a regular user simply needs a short and clear answer on two questions:- is it possible to port a 3.4.0 game with your plugin without rebuilding it (using stable and 3.4.0-compatible engine).- if not, is it possible to rebuild and port 3.4.1 game with your plugin, and will it work properly with 3.4.1 engine.

From what I gathered, answers to both questions is currently NO. Basically, this is where a person should stop trying and wait for further updates.

I would have to go back and investigate the plugin sources to be certain, but I think that it only extracts the prebuilt native libraries (e.g., the Android engine) if those files don't exist. So, in theory it would be entirely possible to just replace those native libraries in the "Compiled/Android/Studio" project folder and rebuild a working APK.

Part of my frustration in this comes from the fact that I've explained the entire process several times to Mehrdad, though I understand that those unseen interactions leave me sounding like a right arse in all this. The plugin itself is just one (minuscule) step further abstracted away from the osd-scourgeoftheunderworld-as Android Studio project, which explains the entirely simple deployment process. The plugin is released as version 0.0, tagged as alpha, and was last updated between build versions of AGS. "Basically, this is where a person should stop trying and wait for further updates" is pretty much the understatement of the year. The process is simple, but with building the Android port from Windows being currently impossible the barrier really falls well beyond the scope of the plugin.

So, the biggest problem is building those native libraries for Android port?Unfortunately I do not know much about whole process. I emailed Sonneveld, as I mentioned in PM, hopefully he can come and discuss these matters.Those libraries is probably something that should not be rebuilt every time. Would it be a viable solution if Nick could upload precompiled libraries?

So, the biggest problem is building those native libraries for Android port?

He also edited the NDK build script, and I'm not certain that his modifications there work on Windows either, but I can't test it at all without the engine's native dependencies. I finally got an installation of Linux under Virtualbox running again (Debian 9 installer kept crashing, so I had to download a different distro). I should be able to rebuild the Android-native Allegro (etc.) and test the NDK build from Windows, or default to downloading the NDK for Linux and run it there.

Those libraries is probably something that should not be rebuilt every time. Would it be a viable solution if Nick could upload precompiled libraries?

Right, there's no reason that the Allegro libraries should have to be rebuilt every time the engine is rebuilt, so if they could be hosted (outside of the repo, obviously) elsewhere that would be ideal.

"Basically, this is where a person should stop trying and wait for further updates" is pretty much the understatement of the year.

I have been following with great interest and am waiting patiently for further updates but this made me smile.

Well... *sigh* Hopefully there will be a temporary fix soon, but the plugin will need to be kept up-to-date with regard to the Android engine files it uses or this whole problem will just resurface. What should be done is that the plugin should have a dependency that the Android engine files exist in an "Editor/Android" subdirectory, and if it can't copy the engine files from there then it can't deploy the APK. That way the engine files can be updated without having to rebuild the plugin.

The way things are now, the Android engine files are packed into "template.zip" from which a(n AGS) project-specific Android Studio project is created (including the engine files), and "template.zip" is packed inside the plugin! :/ Not very well planned out, but in my own defense it was thrown together as more of a proof-of-concept from which to move forward and is versioned as v0.0 (I'll keep shouting it 'til someone hears me! ). The engine files aside, "template.zip" should almost never have to change though, so.... [/technical-details-rant]

I overlooked a rather obvious (albeit less than ideal) workaround to make the plugin work with AGS 3.4.0, which is simply to create a shallow copy of the "Compiled" folder's contents just before running the jobb tool.

That, and reading that Android engine libraries from the editor's directory are included in v0.0.3-alpha. You need to extract "Android.zip" into "EDITOR_DIRECTORY/Android" (so, "EDITOR_DIRECTORY/Android/armeabi/libags_parallax.so", etc.). The rest should work as previously described. I apologize for not thinking of this approach sooner.

I've gotten so far as to verify that I can extract your game data file from the OBB. I haven't yet had time to investigate why it isn't working. I will try and get back to you with further details soon.

Hi Monkey0506Did you find time for test my apk file? Is it possible make an apk with template default AGS game ?

We haven't any PC market in Iran ( My country ). And our country is blocked for any business for Steam , GOG ,... Instead we have a good Android market . That's why I strongly need to this port . Already I fixed Persian fonts with huge help by Crimson Wizard . And I'm waiting long time for Android port. I'm appreciate for any help

I may not have time to investigate this for several weeks at least. Even if the plugin is not working, the processes it use do work. Use the jobb tool and Oceanspirit Dennis Android Studio project files available from my GitHub account. That's the best advice I can give for now.

EDIT2: I installed the Nougat, which is API level 24, using the SDK Manager from Android Studio -> Tools -> Android -> SDK Manager. But Now I am getting "failed to find Build Tools revision 24.0.1". From the SDK Manager-> SDK Tools, I see I have Android SDK Tools 26.0.2 installed. There's no obvious way to get the 24.0.1 SDK from there... :/

EDIT3: Installed build tools 24.0.1. Needed to find my android sdk folder in AppData, in the bin folder, used the command line sdkmanager to install the version with sdkmanager.bat build-tools;24.0.1. Here's a picture on imgur.

EDIT4: So it build correctly ONE TIME. Now it gives me an erro in the console:Unexpected error: Invalid name.Parameter name: name

I have no idea what's that. The only thing I did between builds was removing the RSA Key, because the first build created an APK and an OBB file, when I kinda just wanted an APK... But now even adding the key back doesn't solve my problem...

EDIT5: Ok. I deleted everything, and download my game source again, retraced the steps, left the RSA Key empty and buid the game.apk with everything in it! YEY! Except it doesn't work. I only get a black screen and the app exits...

EDIT6: Opening the Android Studio Project I understand what Mehrdad said, because I am getting the following error (using the Android Monitor):

Hey, if someone knows how to generate a single .APK file (no obb) and make it work, I would be very happy. Maybe I am forgetting something but I have no idea what. Also, from the engine, can I detect it's ran on Android?

Yeah,I meant from script. Ok, if I manage to generate this APK I will use this to pretoggle my touch flag on the game - it sets the text that follow mouse to be fixed on bottom and some other minor adjustments I thought could be useful .