Can I help with Android port?

[fabio]

A lot of work, impressive! You may want to contact Philips on IRC for some tips about opengl. Also historic_bruno ported it to iPhone simulator and did some work on gles iirc, no idea if his changes got committed in a public repository, however.

Did you try it on at least a couple of different devices? Maybe the graphic driver is bugged and responsible for the memory usage, since the pyrogenesis engine is not used in other projects it may trigger some driver problem on some devices (Linux mesa drivers required a lot of fixes before being able to properly run 0 A.D.).

For submitting patches, you should read http://trac.wildfiregames.com/wiki/SubmittingPatches and ask on irc.

[Ykkrosh]

I need someone who knows GL(ES), to help me to fix these errors and also to check/debug the trace(s) to see why it eats that much memory (+1Gb), the problem is that when the game starts, it eats more and more memory until its killed by the OS . At the beginning I suspect the engine has some leaks, that why it continuously eats memory, but I've seen the same thing happens with the retracer on Android, so now I suspect that the GL(ES) commands, somehow are responsible for the leaks.

1GB isn't that much, depending on the map and game settings - if I run on desktop Linux with nos3tc=true (to mirror the lack of working texture compression on Android), on "Greek Acropolis (4)" with default settings, I see resident memory usage ~1.3GB. With S3TC enabled it's ~0.6GB. I think that indicates there's a huge volume of textures, and we don't (yet) have any options to decrease the texture quality or variety, so you just need a load of RAM.

(Texture compression is kind of critical for Android, but ETC1 is rubbish and doesn't support alpha channels, and nothing else is universally available. It would probably be most useful to support ASTC, since that's going to become the most widely available in the future, and has good quality and features.)

Even more, having an application that can replay the trace directly on Android, its great because I could run also benchmarks and it seems that not the CPU is the (main) bottleneck for the slowness, but the GPU. There are frames that have +10k of GL commands, which it seems is a little bit too much for an android tablet

The problem with having a very large number of GL calls is usually the CPU cost of those calls, so the bottleneck might still not be the GPU

[bog_dan_ro]

1GB isn't that much, depending on the map and game settings - if I run on desktop Linux with nos3tc=true (to mirror the lack of working texture compression on Android), on "Greek Acropolis (4)" with default settings, I see resident memory usage ~1.3GB. With S3TC enabled it's ~0.6GB. I think that indicates there's a huge volume of textures, and we don't (yet) have any options to decrease the texture quality or variety, so you just need a load of RAM.(Texture compression is kind of critical for Android, but ETC1 is rubbish and doesn't support alpha channels, and nothing else is universally available. It would probably be most useful to support ASTC, since that's going to become the most widely available in the future, and has good quality and features.)

1gb of ram is huge for a device that has only 2gb for the entire OS.

It seems that s3tc is available on quite a lot of android devices. Is it enabled st runtime? Or I need to set some compile flags?

Here http://developer.android.com/guide/topics/graphics/opengl.html#textures is the complete list of supported formats.

The problem with having a very large number of GL calls is usually the CPU cost of those calls, so the bottleneck might still not be the GPU

as I said my gl skills sucks.

[Ykkrosh]

1gb of ram is huge for a device that has only 2gb for the entire OS.

Oh, sure, but then it's just a problem of the game being fundamentally not designed to run on that kind of hardware, which is a totally different problem to a memory leak bug (though probably a harder one to fix)

It seems that s3tc is available on quite a lot of android devices. Is it enabled st runtime? Or I need to set some compile flags?

It's not available on any devices I've used (Adreno 320/330, Mali-400MP, VideoCore) - as far as I'm aware, only NVIDIA supports it on mobile. But I think the game will use it automatically whenever it's available. (public.zip always contains S3TC-compressed textures, and the game will detect whether the drivers support S3TC, and if not then it will just decompress the textures in software when loading them.)

[bog_dan_ro]

Hello folks,

I've updated AndroidPort wiki page. It will be great if someone will try it, to see setup, compiling, running & debugging works .

I also upload the first patch set here

[bog_dan_ro]

Oh, sure, but then it's just a problem of the game being fundamentally not designed to run on that kind of hardware, which is a totally different problem to a memory leak bug (though probably a harder one to fix)

If the game stays under 1.3Gb it will not be a problem, but it grows way too much and Android kills it.

It's not available on any devices I've used (Adreno 320/330, Mali-400MP, VideoCore) - as far as I'm aware, only NVIDIA supports it on mobile. But I think the game will use it automatically whenever it's available. (public.zip always contains S3TC-compressed textures, and the game will detect whether the drivers support S3TC, and if not then it will just decompress the textures in software when loading them.)

You're right . I digged a little more in this area, and I found that ETC2/EAC has alpha support and is mandatory in OpenGL ES3 (which is available on most Android 4.3+).

Is ETC2/EAC a viable alternative?

[Ykkrosh]

Hmm, ETC2 sounds like it might be good - same bitrate as S3TC (4bpp for RGB, 8bpp for RGBA) and apparently better quality, and a reasonable level of device support.

(Integrating it with the engine might be slightly non-trivial though - we use NVTT to do S3TC compression but also to do stuff like mipmap filtering and to generate the DDS files, so we'd need to find some suitably-licensed good-quality good-performance ETC2 encoder and find some other way to do the mipmaps and create DDS etc.)

[bog_dan_ro]

Hmm, ETC2 sounds like it might be good - same bitrate as S3TC (4bpp for RGB, 8bpp for RGBA) and apparently better quality, and a reasonable level of device support.

Yep, according to this site ETC2 is quite good ;-).

Also Google says: "The ETC2/EAC texture compression formats are guaranteed to be available when using the OpenGL ES 3.0 API. This texture format offers excellent compression ratios with high visual quality and the format also supports transparency (alpha channel)."

(Integrating it with the engine might be slightly non-trivial though - we use NVTT to do S3TC compression but also to do stuff like mipmap filtering and to generate the DDS files, so we'd need to find some suitably-licensed good-quality good-performance ETC2 encoder and find some other way to do the mipmaps and create DDS etc.)

I've found two:

- RwgTex - seems quite good, lots of input/output formats ...

- etcpak - Check this blogpost. It seems it doesn't support ETC2/EAC thought ...

- it seems there is another etcpack from Ericsson which might be open source, but I can't access any of their web sites ... I've found their source code in here https://github.com/paulvortex/RwgTex/tree/master/libs/etcpack , its opensource.

There are other closed-source (but free) encoders available for almost all major platforms.

Edited January 10, 2015 by bog_dan_ro

[Ykkrosh]

- it seems there is another etcpack from Ericsson which might be open source, but I can't access any of their web sites ... I've found their source code in here https://github.com/paulvortex/RwgTex/tree/master/libs/etcpack , its opensource.

That looks like a non-GPL-compatible (and non-OSI) licence, e.g. you're only allowed to distribute source in "unmodified form" and only in "software owned by Licensee", so it's not usable.

- RwgTex - seems quite good, lots of input/output formats ...

That just calls into etcpack, so it has the same licensing problems.

- etcpak - Check this blogpost. It seems it doesn't support ETC2/EAC thought ...

Licence looks okay, but it sounds like quality may be a problem (from the blog post: "As for the resulting image quality, my tool was never intended for production usage").

[bog_dan_ro]

That looks like a non-GPL-compatible (and non-OSI) licence, e.g. you're only allowed to distribute source in "unmodified form" and only in "software owned by Licensee", so it's not usable.

That just calls into etcpack, so it has the same licensing problems.

Ah, I didn't read the license ...

Licence looks okay, but it sounds like quality may be a problem (from the blog post: "As for the resulting image quality, my tool was never intended for production usage").

That was his first version/blog about it, check his latest version/blog. IMHO the biggest problem is that it doesn't support ETC2/EAC ...

[bog_dan_ro]

Hello folks,

I'd like to give you an update:

- Philip' started to upstream my android patches.

- I also checked more the compressed texture status on Android:

* our target should be GLES 3+ devices. Because pyrogenesis needs quite a lot resources, IMHO there is no need to try to target low/mid-end devices.

* use ETC2. Because is the only compressed texture format that is mandatory on all GLES 3+ devices. ASTC is not mandatory nor widely used. Here you can find more infor about the options that we have on Android.

* as you could see from this thread, the only problem is to find an FOSS tool/library the we can use to compress pyrogenesis images. I've found one which is fully FOSS, it's called texgenpack (it also has a page on sf.net). The problem with this tool is that it's quite slow and the compressed image quality is pretty low, comparing with Mali's texture tools.

* anyway, I wanted to check how good is Mali's etc2 comparing with S3TC, so I changed AchiveBuilder a little bit to use Mali's etcpack instead of nvtt and I compressed all textures (with RGBA and mipmaps where needed) using KTX format. After it finished I compare it with S3TC. The (raw) S3TC (dds) images size is ~800Mb and the ETC2 (KTX) images size is ~680Mb, as you can see ETC2 images have ~17% less size, which is good. I also compared a few random images and all ETC2 images looked better than S3TC, which is great .

The problem is still that we don't have a fast FOSS ETC2 library, as Ykkrosh pointed Ericsson's etcpack library is not quite FOSS because it doesn't allow us to change it. I checked a little bit more their source code and it seems that *only* etcdec.cxx has that stupid limitation, the rest of the files seems to be ok. With some effort we can replace etcdec.cxx functions with the one from mesa.

But before we do that, IMHO we should see what's the main use-case of pyrogenesis on Android:

- I think on the fly compression on Android is a no go, it will take ages until a tablet will compress all the textures ...

- On the fly compression on Android, is only needed for custom uncompressed mods and to be able to share a mod with other O.S. (e.g. push a mod from you desktop to your tablet). But is this the main use-case? IMHO no, I think the main use-case will be: wildfiregames will compress all the game data using the best tools available to create the best images, then create a big OBB, and publish it together with the pyrogenesis engine as 0 A.D. Application on google play. 99.99% of Android users will use the Google play application. Anyway, if somebody wants to create a custom compressed mod for android (os just wants to build it himself), then he just needs to have in his $PATH the tool that pyrogenesis ArchiveBuilder uses to compress etc2 textures. Of course the engine will still be able to load and use uncompressed textures, which are needed when we hack on pyrogenesis.

The next step that I'm working now is to add ETC2 support in pyrogenesis. But the engine seems quite tied to S3TC/DDS and I'd like to ask pyrogenesis developers if is ok to do the following changes:

- (at least on Android) use KTX format instead of DDS. KTX is flexible enough to be used in combination with any textures format.

- change a few things to Tex struct :

* instead to "guess" glType, glFormat, glInternalFormat, glBaseInternalFormat needed to upload the textures, I'd like to add this fields directly to Tex struct.

* remove most of TexFlags? The above fields will give us enough information about the texture type (e.g. is compressed, has alpha, etc.)

* do we need (or we'll do in the future) cubemap faces?

- add a new virtual function to ITexCodec which will handle the cubemap faces, mipmaps, this function will be used by "tex_util_foreach_mipmap" to get the cubemap face/mipmaps data instead to compute it itself.

- I think there is no need for TexCodecKtx (the codec that will handle the KTX files) to uncompress on the fly the ETC2 textures, because we know for sure that *all* GLES 3+ devices support it. Of course if pyrogenesis developers will like to use KTX also for desktop, then we'll need to uncompress S3TC textures where the hardware doesn't support it. But, IMHO it should be done ouside of TexCodecXXXXX. If pyrogenesis developers will agree to use KTX everywhere, then I'll volunteer to add KTX support to NVTT .

- change all the other places where the engine assumes that the compressed texture is S3TC and the container is DDS.

Edited January 26, 2015 by bog_dan_ro

[Ykkrosh]

use ETC2. Because is the only compressed texture format that is mandatory on all GLES 3+ devices. ASTC is not mandatory nor widely used.

The Android Extension Pack requires ASTC. The AEP is not mandatory, but GLES 3+ isn't mandatory either - what matters is what the GPU vendors choose to support. (I think even GLES 2.0 wasn't mandatory until KitKat, but pretty much everyone supported it long before that.)

ASTC does seem like it will be widely supported in the future - Mali-T622, PowerVR Series6XT, Adreno 420, Tegra K1. Support is not great right now, but any decent Android port of the game is going to be a long-term project, and if we're going to spend effort on new texture compression formats I think it may be better to spend the effort on one with better long-term prospects.

(And ASTC has better quality at the same bitrate, and much more flexibility in choosing bitrates (possibly the most useful feature - we can trade off quality against memory usage and texture bandwidth), so if compatibility was equal, it would be the better choice.)

The (raw) S3TC (dds) images size is ~800Mb and the ETC2 (KTX) images size is ~680Mb, as you can see ETC2 images have ~17% less size, which is good.

I still don't see how that's possible - S3TC and ETC2 are both 4bpp for RGB (and for RGB with 1-bit alpha), and both are 8bpp for RGBA, and the DDS/KTX headers should be negligible, so there should be no difference, as far as I understand.

I think on the fly compression on Android is a no go

Slightly tangential, but a possible use case for on-the-fly compression:

Currently we render terrain with a lot of draw calls and a lot of alpha blending, to get the transitions between different terrain textures - I think a blended tile needs at least 7 texture fetches (base texture + shadow + LOS, blended texture + shadow + LOS + blend shape), sometimes more. That's not very efficient, especially on bandwidth-constrained GPUs (e.g. mobile ones). And it's kind of incompatible with terrain LOD (we can't lower the mesh resolution without completely destroying the blending).

I suspect it may be better if we did all that blending once per patch (16x16 tiles), and saved the result to a texture, and then we could draw the entire patch with a single draw call using that single texture. It'll need some clever caching to make sure we only store the high-res texture data for patches that are visible and near the camera, and smaller mipmaps for more distant ones, to keep memory usage sensible, but that shouldn't be impossible.

But if we do generate the blended terrain textures at runtime like that, we need to compress them, to get the best quality and memory/bandwidth usage. So we'll need a suitably-licensed compression library we can use at runtime (though one that focuses on performance over quality; and if I can dream, one that runs in OpenCL or a GLES 3.1 compute shader, since the GPU will have way more compute power than the CPU, and this sounds like a trivially parallelisable task that needs compute more than bandwidth).

(Civ V appears to do something like this, though its implementation is a bit rubbish (at least on Linux) and has horribly slow texture pop-in. But surely we can do better than them...)

- (at least on Android) use KTX format instead of DDS. KTX is flexible enough to be used in combination with any textures format.

DDS is also flexible enough to be used in combination with any texture format, so I don't think that's an argument in favour of KTX . Using two different texture containers seems needlessly complex. We could switch the generated textures to KTX on all platforms, but we still need to support DDS input because lots of the original textures in SVN are DDS (from the days before we supported PNG input), and it sounds like more work than just updating our DDS reader to support a new compression format.

* do we need (or we'll do in the future) cubemap faces?

We currently use cube maps for sky reflections, though the actual inputs are single-plane image files and we generate the cube maps in a really hacky and very inefficient way. That ought to be rewritten so that we load the whole cube map efficiently from a single compressed DDS/KTX file.

In general, changing our texture code is perfectly fine - it has evolved slightly weirdly, and it supports features we don't need and doesn't support features we do need, so it would be good to clean it up to better fit how we want to use it now. (I don't know enough to comment on your specific proposals off the top of my head, though . Probably need to sort out the high-level direction first.)

I'll volunteer to add KTX support to NVTT .

NVTT hasn't had a release for about 5 years, and we want to rely on distro packages as much as possible, and they only really want to package upstream's releases, so changing NVTT is a pain . (The distros include a few extra patches we wrote to fix some serious bugs, but I doubt they'll be happy with a big non-upstream patch adding KTX support and changing the API). It'd probably be less effort to write some code to transcode from DDS to KTX, than to get NVTT updated.

[Ykkrosh]

But if we do generate the blended terrain textures at runtime like that, we need to compress them, to get the best quality and memory/bandwidth usage.

Mmm... Having read the ASTC spec, I'm not sure there's much chance of a real-time encoder with decent quality - there's a huge number of variables that the encoder can pick, and if it tries to pick the optimal value for each variable then it's probably going to take a lot of time, and if it doesn't then it's just wasting bits. ETC2 might be more appropriate for that case, since it's much simpler and will presumably take much less encoding time to get close to optimal output. Might be interesting to do a test of quality vs encoding speed though, to see if that's true.

[bog_dan_ro]

The Android Extension Pack requires ASTC. The AEP is not mandatory, but GLES 3+ isn't mandatory either - what matters is what the GPU vendors choose to support. (I think even GLES 2.0 wasn't mandatory until KitKat, but pretty much everyone supported it long before that.)

ASTC does seem like it will be widely supported in the future - Mali-T622, PowerVR Series6XT, Adreno 420, Tegra K1. Support is not great right now, but any decent Android port of the game is going to be a long-term project, and if we're going to spend effort on new texture compression formats I think it may be better to spend the effort on one with better long-term prospects.

(And ASTC has better quality at the same bitrate, and much more flexibility in choosing bitrates (possibly the most useful feature - we can trade off quality against memory usage and texture bandwidth), so if compatibility was equal, it would be the better choice.)

Well, if my proposed changes (using KTX, change Tex struct, etc) are ok with you, then we can switch at any time, to any texture type, without changing a single line in the engine . All the information we need to upload and use the texture is in the KTX file.

I still don't see how that's possible - S3TC and ETC2 are both 4bpp for RGB (and for RGB with 1-bit alpha), and both are 8bpp for RGBA, and the DDS/KTX headers should be negligible, so there should be no difference, as far as I understand.

I have no idea why , but I'm more than happy to share the changes that I did to the engine to compress the textures as ETC2. Considering that I did it in a few minutes, maybe I did something wrong ...

DDS is also flexible enough to be used in combination with any texture format, so I don't think that's an argument in favour of KTX . Using two different texture containers seems needlessly complex. We could switch the generated textures to KTX on all platforms, but we still need to support DDS input because lots of the original textures in SVN are DDS (from the days before we supported PNG input), and it sounds like more work than just updating our DDS reader to support a new compression format.

I *briefly* checked DDS format and it doesn't seem to be as good as KTX (at least for OpenGL, it's quite inferior). KTX header contains everything we need to use *any* texture without changing a single line in the engine (of course the GPU must support it, at least on Android, it will not be a problem). IMHO switching to KTX format is a step forward. I totally agree with you that we need to support DDS format an input (Mali's etcpack supports lots of formats for input, including DDS ;-) ).

In general, changing our texture code is perfectly fine - it has evolved slightly weirdly, and it supports features we don't need and doesn't support features we do need, so it would be good to clean it up to better fit how we want to use it now. (I don't know enough to comment on your specific proposals off the top of my head, though . Probably need to sort out the high-level direction first.)

Ok, then I'll start with incremental changes (e.g. adding TexCodecKtx, and changing the Tex struct.

NVTT hasn't had a release for about 5 years, and we want to rely on distro packages as much as possible, and they only really want to package upstream's releases, so changing NVTT is a pain . (The distros include a few extra patches we wrote to fix some serious bugs, but I doubt they'll be happy with a big non-upstream patch adding KTX support and changing the API). It'd probably be less effort to write some code to transcode from DDS to KTX, than to get NVTT updated.

Ah, I didn't know it is that difficult to upstream patches to NVTT. Ok, then I'll write a converter inside our project.

[Ykkrosh]

I have no idea why , but I'm more than happy to share the changes that I did to the engine to compress the textures as ETC2. Considering that I did it in a few minutes, maybe I did something wrong ...

Ah, looks like the ALPHA_PLAYER is the problem - that still needs to be 8-bit alpha. I think there are approximately no cases where we can use 1-bit alpha formats (since even if the original texture has only 1-bit alpha, its mipmaps will need higher alpha resolution). I think we currently use no-alpha DXT1 (4bpp) for any textures whose alpha channel is entirely 0xFF, and DXT5 (8bpp) for everything else.

[bog_dan_ro]

Hello folks,

I have some good and not so good news to share with you

Let's start with the good news:

- I managed to use ETC2 + KTX textures on Android!

- The memory usage (RSS) now stays under 750Mb which is great! On my phones the game is not killed anymore by the O.S.. It's still a lot but at least it survives

- The game speed is ~the same as using uncompressed textures. It feels faster when it starts.

Now the bad news:

- I could not make incremental changes, the S3TC was quite tight integrated into the engine.

- Because the patches are big I did some mistakes and now (only) the fonts are screwed (on Android and on Desktop as well). Sadly I tried to fix it, but I failed ...

If anyone can help to fix the fonts problem it will be very much appreciated!

The repo is on my github fork: https://github.com/bog-dan-ro/0ad ktx branch. Last 5 commits are KTX/ETC2 releated.

Steps to compress the textures for android using etc2:

- download Mali's texture tool

- unpack it and make sure etcpack is in your $PATH

- use the same branch to build a non-android version of the game, the run :

$ mkdir temp
$ binaries/system/pyrogenesis -archivebuild=binaries/data/mods/public -archivebuild-output=temp/public.zip -archivebuild-compress -etc2
$ binaries/system/pyrogenesis -archivebuild=binaries/data/mods/mod -archivebuild-output=temp/mod.zip -archivebuild-compress -etc2

[historic_bruno]

I wonder how well the game would run on one of these Android mini pcs? I've had it barely run on a Raspberry Pi (not practical), but recent Android PCs-on-sticks appear to have much better specs like multicore CPUs and more RAM.

[niektb]

Maybe it runs 'well' on the Pi 2 model B?

[bog_dan_ro]

I wonder how well the game would run on one of these Android mini pcs? I've had it barely run on a Raspberry Pi (not practical), but recent Android PCs-on-sticks appear to have much better specs like multicore CPUs and more RAM.

In principle it should "work" on any GLES 3.x devices (GLES 3 is needed for ETC2). The problem is that 0 A.D. struggles to run on my high-end devices . I own one of these android mini pcs and from my experience they are not that powerful. Yes the hardware is *much* better than Pi (even much better than Pi2) but still not enough to run flawlessly 0 A.D. ...

[bog_dan_ro]

In principle it should "work" on any GLES 3.x devices (GLES 3 is needed for ETC2).

Actually using KTX instead of DDS doesn't require the textures to be ETC2. You can compress them with anything that device supports and it should work without any changes in the game engine. Of course you need to find a way to compress them, so most probably you'll end up doing some changes in AcrhiveBuilder&TextureConvert classes.

[bog_dan_ro]

- Because the patches are big I did some mistakes and now (only) the fonts are screwed (on Android and on Desktop as well). Sadly I tried to fix it, but I failed ...

I managed to fix half of the fonts probems, now only the bold fonts are screwed . I've also seen that there are a few problems with the terain textures and the corner of the message windows.

[fabio]

Hi, if someone is interested in testing, bog_dan_ro uploaded an updated android apk + mod and public mods zip here: http://trac.wildfiregames.com/ticket/2996#comment:45

Install the apk, start it and it should create some empty dirs in sdcard. Locate 0ad/appdata/data/mods dir and copy the two zips inside it in mod/mod.zip and public/public.zip

The game should then be able to run.

Note: the game requires OpenGL ES 3.0 to run.

For bog_dan_do: I tried your latest packages and can confirm the same issues I got with the archive I built myself on my Nexus 7, reported at http://trac.wildfiregames.com/ticket/2996#comment:43

Unfortunately I am a bit busy to further debug the problems as described at http://trac.wildfiregames.com/ticket/2996#comment:44 , if someone can it could speed up android support .

[bog_dan_ro]

I'm going to make it simple to test. I'm going to use publish it on google play in the alpha area, using my own account and with a different package name to allow wildfiregames to publish it using the real package name when the game will be production ready.

People who want to test it, they need to do the following steps:

• join https://groups.google.com/forum/#!forum/wildfiregames google group. I just created it a few minutes ago and I really like to give it to windfiregames sysadmins, so sysadmins please send me a mail or PM and I'll pass you the ownership.
• after you've joined wildfiregames group, hopefully you'll get a message from google play when the package will be published (I upload it a few minutes ago, but it takes some time until it gets published, so please be patient!).
• This is the link to testing package
• follow the instructions from that link.

A few words about its status:

• You need a device with GLES 3.0 or better.
• You need a mouse because, currently, is not touch friendly at all. Sadly I have no idea how make it touch friendly ...
• Even now it looks stable (no more crashes I hope) don't forget that the game runs very slow even on high end devices.
• If it crashes, I need the logcat from your device!

I don't think I'll have enough time to update to than once in a week and only if there are changes that matters.

Edited March 8, 2015 by bog_dan_ro

[WhiteTreePaladin]

I tried it on a Nexus 7, and it just changes the screen to black and landscape, and then immediately returns. I guess it is crashing. I don't know anything about Android development; where is logcat?

[fabio]

@WhiteTreePaladin: bog_dan_ro quote from IRSC some days ago on using logcat:

you need to add your device usb id to /etc/udev/rules.d

check http://developer.android.com/tools/device.html#setting-up

search for "Log in as root and create this file"

lsusb will tell you the id

I tried the new version from Google Play on my Nexus 7 with Android 5.0.2:

• uploading technical feedback apparently succeeds now;
• the interface is no longer scaled (that caused overlapping buttons);
• I noticed it now installs with an OBB file;
• I was able to connet to the lobby and chat (the keyboard get activated when required);
• opening web links pressing the menu buttons still doesn't work;
• when the keyboard is removed from the screen the Android 3-buttons menu bar stays active hiding the bottom of the screen;
• every tap counts as two clicks, just go in the Options window and I cannot change anything (a tap quickly enable and disable it); it works fine if I press the touch screen for a longer time; it would be more intuitive to invert this behavior;
• it crashes as soon as I start a match at 99/100% loading (also I tried starting a match on a Tiny random map whit just 1 player), so I cannot test the game itself.

Yes, I still need to try logcat myself.