Google Play shows app only on 3000 over 13K devices on which the game should run just fine

Hi there!

I’m a bit anxious because, even anticipating to the client that the game prerequisites would have been higher than usual due to the requested features and visuals, the game doesn’t run right on two of the client’s test mobile phones: Samsung A10 (2019), Samsung Galaxy J3 (2017) SM-J330FN, 2g ram.

My first thought was that I was requiring OpenGL ES 3.x to run, but both support it!
Needless to say, the game actually runs on a “relevant” percentage of “relevant” mobiles, but I’m struggling to find a reason it doesn’t run on those 2, and maybe more devices, since they have the prerequisites (looking at the tech sheets, both support GL ES 3.2).

On the contrary, it does run pretty well on older devices (Xiaomi Mi A1, and older), so I’m really puzzled.
I tested on older devices: no issues.

I searched through the forums, so I can share the AndroidManifest.xml included in the APK (even if, I uploaded a .AAB on Google Play, hopefully the generated APKs share the same manifest). I extracted this by using the APK Analyzer of Android Studio.

Here it is:
AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="954"
    android:versionName="1.0.954"
    android:installLocation="2"
    android:compileSdkVersion="28"
    android:compileSdkVersionCodename="9"
    package="com.notrelevant"
    platformBuildVersionCode="28"
    platformBuildVersionName="9">

    <uses-sdk
        android:minSdkVersion="21"
        android:targetSdkVersion="28" />

    <supports-screens
        android:anyDensity="true"
        android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true" />

    <uses-feature
        android:glEsVersion="0x30000" />

    <uses-feature
        android:name="android.hardware.vulkan"
        android:required="false" />

    <uses-permission
        android:name="android.permission.INTERNET" />

    <uses-permission
        android:name="android.permission.VIBRATE" />

    <uses-feature
        android:name="android.hardware.touchscreen"
        android:required="false" />

    <uses-feature
        android:name="android.hardware.touchscreen.multitouch"
        android:required="false" />

    <uses-feature
        android:name="android.hardware.touchscreen.multitouch.distinct"
        android:required="false" />

    <uses-permission
        android:name="android.permission.READ_LOGS" />

    <application
        android:theme="@ref/0x7f030001"
        android:label="@ref/0x7f020000"
        android:icon="@ref/0x7f010000">

        <activity
            android:label="@ref/0x7f020000"
            android:name="com.unity3d.player.UnityPlayerActivity"
            android:launchMode="2"
            android:screenOrientation="6"
            android:configChanges="0x40003fff"
            android:hardwareAccelerated="false">

            <intent-filter>

                <action
                    android:name="android.intent.action.MAIN" />

                <category
                    android:name="android.intent.category.LAUNCHER" />
            </intent-filter>

            <meta-data
                android:name="unityplayer.UnityActivity"
                android:value="true" />
        </activity>

        <meta-data
            android:name="unity.build-id"
            android:value="bc094184-46bf-4c19-bb9f-f22a80e8e1ef" />

        <meta-data
            android:name="unity.splash-mode"
            android:value="0" />

        <meta-data
            android:name="unity.splash-enable"
            android:value="true" />
    </application>
</manifest>

Here are my Project Settings:

Do you have any clues?

I understand that setting OpenGLES 3.x as a prerequisite cuts out many devices but I really can’t explain which is the setting that is cutting off most devices.

Could you please help me? What’s your experience?

My guess would be the installed RAM which reasonably should be 2GB or more (I have tons of unique, crunched 2K textures), but how can I predict the RAM prerequisites or lower them (assuming the hard cut Google did it’s due to the RAM usage)?

comparing those 3,

GPU is different…
also could be texture compression setting/override? (ive seen some topics related to that before)

1 Like

Yup, I’m coming right from a topic where a user was forcing a specific texture compression, but that was evident in the Manifest.xml.
Not my case :confused:

In mine, I really don’t know also because (extra info)

  • I used automatic settings (no overrides of the default compression method/format)
  • All texture are POT
  • Google provides such info without even running the game
  • It happens on install, (the install fails), so no code is ever ran
  • Even using a directly installed APK instead of the Google AAB to APK rebuilt package from the Play Store, the install fails

A very common import setting I’m using is this (for lightmaps)

which is acceptable to me (Mipmapping is not really useful for rendering rooms on mobile, I can use some extra build space), since I can reach 150KB from a 5MB lightmap, with acceptable artifacts (increasing padding a bit almost fixes that)

Unfortunately I can’t target OpenGL ES 2.x device mostly because of this:

Low Quality is terrible (heavy color quantization) and to enable Normal Quality, I have to remove OpenGLES2 support :confused: (it’s the Unity IDE that asks me to do so)
I wish there was a workaround for that.

But, even with a workaround, I can’t explain what is wrong with my settings and the S A10/Galaxy J3 :confused:

I mean, I don’t feel like I hardcoded anything special. Unless it’s implicit.

I don’t know, maybe it’s texture crunching?

My current build covers 95% of all devices supporting GL ES 3.x AND having more than 2GB of RAM, which are reasonable for my project, but a lot of mobiles have been cut out for no clear (to me) reason.

I’m hoping someone could shed some light on this.

You only have ARM64 selected in the player settings. AFAIK the A10 uses a 32bit kernel.

Edit: Same for the J3 : SM-J330FN - Geekbench Search - Geekbench

1 Like

This one has a Mali-400 GPU, which is OpenGL ES 2.0 only, so it won’t work there.

Side note - you can remove Vulkan from the graphics API list. It comes after OpenGL ES 3, so it won’t ever be selected.

1 Like

Thanks for answering!

Yes, that’s true, but I’m pushing an AAB to Google Play. I was assuming those settings didn’t apply when exporting as AAB.

was my assumption wrong?

(btw, that’s interesting, I remember to have researched they were both 64 bit and ES 3.2 compliant. Maybe they were “approximated” tech sheets for the “average end user” only? Maybe my sources weren’t good, thanks for sharing them :slight_smile: )

Thanks @aleksandrk ! I noticed about both being Mali processors, but I’m really not so experienced in the hardware side.
Thanks for the tip, I left it “just in case”, but surely has no sense to be there, unless I force Vulkan to be the only one option. Something that, according to my researches of several months ago, may be not a good idea :slight_smile:

To recap, please correct me if I’m wrong, I’d appreciate if I could double check what I understood :slight_smile:

  • I still have to check both ARM v7 and ARM64 when exporting an AAB (first game I’m exporting with AABs) - Google won’t support any extra architecture if not those checked in the Unity IDE. x86 is useless

  • My info was wrong on both mobiles, so it wasn’t because of insufficient RAM, but due to the fact the they both have 32bit CPUs and both (or, at least, the J3) Mali GPUs don’t support OpenGL ES 3.0

  • Even if both mobile models supported ES 3.0, my build was targeting ARM64 only, so I should check also ARMv7 to increase the supported mobiles count

  • I found that the samsung_galaxy_a10-9580 (GSMarena) mounts the Mali-G71 MP2, which should support OpenGL 3.2

  • The A10 is actually the only model capable of running my game, after I enable support for ARMv7

  • I’m a bit ashamed to ask confirmation about this, but: there is no existing mobile supporting Vulkan but not OpenGL ES 3.0. Or, it would be such a black sheep to not justify the effort.

Are 1,2,3,4,5,6 correct? :slight_smile:

1: correct
2: Only J3 doesn’t support OpenGL ES 3.0, otherwise correct
3, 4, 5: correct
6: Vulkan cannot run on hardware that doesn’t support OpenGL ES 3.1

If you include Vulkan there, you get all shader compiled and bundled for Vulkan as well, which increases your app size and build time. So don’t leave it there “just in case” :slight_smile:

1 Like

Are you sure about that? I’m finding that it uses Mali-T720, which does support ES 3.0+. ( https://www.sammobile.com/samsung/galaxy-j3-2017/specs/SM-J330FN/ )

Yep, I’m correct, the SM-J330FN version has the Mali-T720. I believe this is a slightly newer and European only version, while a slightly older US only version has a Mali-400. Why Samsung keeps varying the specs between regions this much is anyone’s guess.

So @NeatWolf , I believe after you add ARMV7, it should be working on both phones.

1 Like

About 6, I shamelessly admit my ignorance :smile: , thanks for explaining the reason, now I know… and double thank you, because I’m trying to scrape every single MB for the build :stuck_out_tongue:

That would be good news, since I also found written around that it was 3.0 compatible.

If that’s true (and I will confirm it with my next build, after Unity re-imports everything after removing Vulkan support :smile:), that would mean that enabling ARM v7 support, the game would run on both.

About the Mali-T720 I found a vintage review from 2013 with this pic:

So, well, it may run, but I seriously doubt it will reach the 60fps cap :smile:

EDIT: oh, you edited the message right a sec after I quoted you, I believe we ended up to the same conclusion :slight_smile:

1 Like

Ah, right, I looked at the 2016 version.

Little update:

The issue was definitely my fault :sweat_smile:

I’m not sure how or why I assumed that state of the ARM v7/64 wasn’t relevant when exporting as AAB.

Actually, I have a theory: since a help box appears right in that point, telling that “splitting binaries was disabled since I’m exporting a Google AAB”, I must have incorrectly assumed by transferring that principle on the nearby section.
So my mind read “splitting APKs/builds/architectures has no meaning since you’re exporting for Google”.

I know it sounds weird, but I believe that’s what happened. Not sure if this could be helpful as a feedback for the UI.
I was really really convinced about my unconscious assumption :smile:

— long story short —
the game now runs on both (and more) devices, but it’s really unplayable on the J3 (as expected)

Also, thanks again for that advice @aleksandrk !
Removing Vulkan support shrank the build size of at least 20MB on a total of 130MB. Which, for me it’s an insane gain in build space. :stuck_out_tongue:
Thanks again! :slight_smile:

2 Likes