Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
New Forum User Notice Update to the Unity Editor Software Terms

Stress out Google to set up more filtering options in the Market!

Discussion in 'Android' started by PolyMad, Jan 4, 2011.

  1. PolyMad

    PolyMad

    Joined:
    Mar 19, 2009
    Posts:
    2,342
    PolyMad, Jan 4, 2011
    #1

  2. eriQue

    eriQue

    Unity Technologies

    Joined:
    May 25, 2010
    Posts:
    595
    But Unity already does that filtering. And the Market filters are already there to support that. A normal Unity game will not show up on a non-ARMv7 device, and it will only be listed on GLES2.0 devices if GLES2.0 is used.

    The Samsung problem is a completely different thing; some Samsung devices have a bug in the kernel in the pre 2.2 OS. Sounds like you really want is a do-not-install-on-Samsung-pre-2.2 filtering option? The only way around that today is to have minSdkVersion set to 2.2 instead of 2.0.
     
    eriQue, Jan 5, 2011
    #2

  3. DanTreble

    DanTreble

    Joined:
    Aug 31, 2010
    Posts:
    590
    This *10, thanks megmaltese!

    Which filtering? If I put an ARMv6 + ARMv7 app on the market, ARMv5 users will be able to download it, it will then crash for them and I'll get terrible ratings. Having a way to filter ARMv6 would give us a larger potential market without the potential ARMv5 crashes and bad reviews.

    Yeah, this really is a pain. According to app brain our largest market segment (at 20%) are Samsung Galaxy S phones. Despite the warning, so many people then try and run the game, it crashes then they give it a terrible review. Or worse, one review said "If it crashes, keep trying it, it worked for me 7th go, Samsung Facinate" if I remember correctly.

    I would love to be able to filter these out so people don't have a bad experience, while letting other 2.1 phones through...

    For some reason we still don't show on the Xperia 10 either, did I read somewhere it incorrectly reported it's GL version maybe?
     
    DanTreble, Jan 5, 2011
    #3

  4. eriQue

    eriQue

    Unity Technologies

    Joined:
    May 25, 2010
    Posts:
    595
    Are you talking about Unity 3.2 (ie unreleased product still in beta) now? With Unity 3.0 and 3.1 you should never ever put an .apk built with ARMv6+ device filter on the market; then you get crashes on _all_ non ARMv7 devices. That option was there only to deal with Tegra dev boards which wrongly identified themselves as ARMv5. Unity pre 3.2 only supports ARMv7.

    If you are asking to add filtering mechanism for VFP/NEON, then I'm all with you; Google should do that imho ;)
    But the 3.2 ARMv6 w/ VFP option can be coupled with a GLES 2.0 limiter to narrow the scope of potential installations to devices with ARMv6 w/o VFP. Still, 3.2 is not released and discussions regarding features that may (or may not) be in 3.2 is best kept to the beta list.
     
    eriQue, Jan 5, 2011
    #4

  5. PolyMad

    PolyMad

    Joined:
    Mar 19, 2009
    Posts:
    2,342
    So, we don't need to bother at all with that because you produce and APK with the right manifest that will filter out all the devices that are non ARM7 or non OpenGL2 ?

    By the way, can I widen a bit my consumer audience by making games with OpenGL1 or that's almost useless?
    Because I aimed at a type of graphics that is ok even on OpenGL1 but if you (or whoever) can tell me that OpenGL1 devices are almost 0 around then I'll go straight for OpenGL2 :)

    Did you check my game, Erique? :D
     
    PolyMad, Jan 5, 2011
    #5

  6. eriQue

    eriQue

    Unity Technologies

    Joined:
    May 25, 2010
    Posts:
    595
    Yes, that is exactly what the Device Filter option does for CPU architecture, and Graphics Level does for GPU driver architecture.

    We can break it down like this:
    # of models based on ARMv7, but that only supports GLES 1.0/1.1 : 0 (to my knowledge)
    # of models based on ARMv5/6 and only support GLES 1.0/1.1 : quite many
    but:
    # of models based on ARMv5/6 with VFP support (which is a Unity requirement; i.e. could potentially run Unity in the future), but still only support GLES 1.1 : probably very few (I don't know a single device that falls into this category at this point, but I'm sure they exist).

    There are other considerations to take into account though; targeting GLES2.0 type of graphics might include heavier shaders, and a weaker GLES2.0 architecture might suffer from bad performance with such a layout.
     
    eriQue, Jan 5, 2011
    #6

  7. PolyMad

    PolyMad

    Joined:
    Mar 19, 2009
    Posts:
    2,342
    Ummm... is it right if I translate all that to: "I would recommend sticking to OpenGL1 because you can meet weaker OpenGL2 architecture and find performance problems"? :D

    On a completely generalized way, I would like to know if sticking to OpenGL1 will earn me something like 10% or 20% or 30% more devices on the Market.

    Because if it's like 10% I will let them away: better have a boosted graphics for 90% of the devices than a lower level graphics for 100% of the devices around.

    And, after this consideration, it would be nice to know the same % about the "weak" OpenGL2 architecture.
    Same consideration applies: if the problematic OpenGL2 architecture are a 10% of the total OpenGL2 available machines on the market, I'll let them away and just specify that if low framerate is due to weak machines, but if the amount of weak OpenGL2 architecture amounts to, let's say, 30% of the devices around, then I think it's better to stick to OpenGL1 and earn all that important slice of the market and don't make them unhappy :D
     
    PolyMad, Jan 5, 2011
    #7

  8. eriQue

    eriQue

    Unity Technologies

    Joined:
    May 25, 2010
    Posts:
    595
    Not really; I was talking about GLES 2.0 type of graphics, meaning complex shaders and perhaps fullscreen post processing fx, and what not.
    Doing exactly the same type of graphics with GLES 2.0 as GLES 1.1 (like, simple texture modulation) will have the same performance (minus (what I would say) negligible overhead for emulation of 1.1 (either by Unity or the graphics driver)).
    So, the question then more becomes a matter of how advanced shaders you want to use: I.e. the performance you can live with on the lower end devices vs. how good your game will look on the higher end devices.

    I was (in an attempt to predict the future) merely trying to point out that by adding support for more devices (outside the ARMv7 range) there will potentially be weaker devices in that batch (i.e. slower CPU/GPU). You can still opt out on those and go with ARMv7 only, which generally has a more powerful CPU/GPU. (Unity will then be able to use more optimized code paths and the market filters will update accordingly).
     
    eriQue, Jan 5, 2011
    #8

  9. DanTreble

    DanTreble

    Joined:
    Aug 31, 2010
    Posts:
    590
    Goodness no. I'm running 3.1 as we speak and it has an ARMv6 option in the dropdown, I was just curious.

    Noted :)

    Totally. I'd still take the samsung 2.1 filter as well :)

    I know unity relies on VFP SIMD, my mind boggles as to how bad it runs without it. In my experience, SIMD can make grate improvements in small inner hand coded loops. However when sprinkled through your application in a vector class, it wasn't much of a win. I'm used to being bound by memory and cache misses rather than instruction throughput.

    The future sounds exciting :)
     
    DanTreble, Jan 6, 2011
    #9

  10. DanTreble

    DanTreble

    Joined:
    Aug 31, 2010
    Posts:
    590
    GLES2.0 could potentially be faster on the same device as GLES1.x. GLES2.0 includes support for vertex buffer objects and compiled shaders which _could_ be faster than multiple attribute vertex arrays and a fixed function shader.

    Not sure if unity uses VBO's in 2.0 mode though?
     
    DanTreble, Jan 6, 2011
    #10

  11. eriQue

    eriQue

    Unity Technologies

    Joined:
    May 25, 2010
    Posts:
    595
    It's a common misconception that VFP is only about SIMD; VFP has a scalar part as well. And an ARMv5/6 without VFP is effectively like a CPU without any kind of simple scalar FPU; there are no 'hardware' floating point instructions. Meaning, floating point addition / multiplication / etc has to be emulated in software. (See the Wikipedia article about ARM VFP),
    For comparison, even the first generation iOS devices (like 1st gen iPod Touch) had VFP.
    (For completeness I should mention that there are other implementations of FPU in ARM architecture, not only VFP. But they are from Android perspective irrelevant)
     
    eriQue, Jan 6, 2011
    #11

  12. DanTreble

    DanTreble

    Joined:
    Aug 31, 2010
    Posts:
    590
    Oh wow, no FPU, well then I completely understand. Software float emulation isn't great and converting into fixed point wouldn't be an option.
     
    DanTreble, Jan 6, 2011
    #12

  13. deepak

    deepak

    Joined:
    Aug 10, 2010
    Posts:
    44
    Hi erique

    We had developed a game for android and its up in android market.. but when i tried to download the same application in SAMSUNG GALAXY TAB its not getting downloaded. We got a review from a user the same problem. Any solution?

    Thanks
    Deepak
     
    deepak, Apr 1, 2011
    #13

  14. eriQue

    eriQue

    Unity Technologies

    Joined:
    May 25, 2010
    Posts:
    595
    If the problem is not whether the application shows up in the Market app on a potentially unsupported devices then it's probably not related to this thread at all.
    But, if your application shows up the Galaxy Tab, and you are 'allowed' to download it but the download then fails, it could be that you're hit by the 25-30MB download limit of Samsung devices. The problem is the size of the cache drive, and the issue has been discussed in various places on the internets, like here : people-cant-download-our-specific-product-in-android-market
     
    eriQue, Apr 1, 2011
    #14

  15. bigcheese_

    bigcheese_

    Joined:
    Sep 6, 2011
    Posts:
    31
    I have a couple of questions regarding this matter.

    First I tried putting 2 builds on the market one with ARMv7 and the other with ARMv6 with VFP (thats from Unity 3.5 with both using GLES 2.0) I get this message on the "APK Files" tab "Error: APK version 1006 supports all the same devices as other APKs with higher versions. It would not be served. Please deactivate an APK." however after putting the 2 APKs instead of the ARMv7 one alone, the supported devices on the "Product details" tab increased from 818 to 1206. Does this mean that devices with ARMv7 will see the ARMv7 APK and devices with on ARMv6 will only see the ARMv6 build ? (should I ignore the error message) ?

    Another question is with the Texture compression filtering.
    I have different builds for different Texture compressions, PVRTC/ATC/DXT/ and one with no compression. all with version codes from higher to lower respectively.
    Now If I upload any of them (the android market will always show the same number of devices supported) take for example the Galaxy S, it supports PVRTC, however if I only upload the ATC or DXT package, it will be shown as a supported device. in this case I don't have much of a problem since the PVRTC have the 1st priority. but say in the case of a device that supports ATC (adrino, say Xperia S) according to this, it will give the priority to the PVRTC APK instead of the ATC one. This is the 1st time for me to upload to the android market, should I rely on the feedback from the Google play ?

    Also, considering that the Galaxy S2 which doesn't support any of the (PVRTC/ATC/DXT) compressions, will it go for the default (uncompressed) one ?
     
    bigcheese_, Jun 6, 2012
    #15

  16. bigcheese_

    bigcheese_

    Joined:
    Sep 6, 2011
    Posts:
    31
    Seems like the "Product details" tab, it only filters this
    Supported Devices This application is only available to devices with these features, as defined in your application manifest.

    Screen layouts: SMALL NORMAL LARGE XLARGE
    Required device features
    android.hardware.screen.portrait
    android.hardware.touchscreen
    android.hardware.touchscreen.multitouch

    So it seems, the gl texture and the ARMv6/ARMv7 are not supported.
     
    bigcheese_, Jun 6, 2012
    #16

  17. mbernasocchi

    mbernasocchi

    Joined:
    Jun 12, 2012
    Posts:
    1
    Hi guys, sorry I'm not familiar with unity, but I'm very interested in how you archive cpu architecture fitering in google market. How do you filter armeabi v5 from v7?
    thanks a lot
    Marco
     
    mbernasocchi, Jun 12, 2012
    #17

  18. eriQue

    eriQue

    Unity Technologies

    Joined:
    May 25, 2010
    Posts:
    595
    By putting the native libs in proper subfolder in the .apk

    lib/armeabi/xxx <- armv5
    lib/armebi-v7a/xxx <- armv7
    lib/x86/xxx <- x86

    and so on.
     
    eriQue, Jun 12, 2012
    #18