Question

For my app, I want 3 categories of performance:

"BASELINE_CONSTRAINED" - for older devices, made before 2012

"BASELINE" - 2012-2013 ..."now" ..."standard"

"BASELINE_EXTENDED" - High-end devices, bleeding edge.

I've done this on iOS no problem -- less devices to wrangle, so I can specifically set by device ID.

But with 4000+ device types on Android, what's the best way to find devices by "ship date"?

Thoughts: - Some combination of DPI and Screen Size? - Android SDK X ...but people can upgrade - Processor speed? - how about build.prop "date" -> ro.build.date=Sat Nov 17 16:10:21 GMT 2012

Thanks in advance!

Was it helpful?

Solution 2

Update:
While I still use the approach below to reduce the device compatibility to only "newer" and larger screen devices -- which is required for my application -- I ended up needing even more control.

I found that the android hardware platform is always(?) incorporated into the /system/build.prop file. It's the most reliable property I've found when testing across about a dozen devices (every manufacturer decides to put different properties in there, and very few like to report on CPU speed or complete graphics card capabilities).

Using the hardware platform, I can reliably separate out the top-tier devices from the rest.

I call this "performance class".

Class 1 = my lowest end devices.

Class 2 = my baseline device (as of right now)

Class 3 = my highest end devices.

const SD600:Array = ["APQ8064T","APQ8064AB","APQ8064-1AA","APQ8064-DEB","APQ8064-FLO","APQ8064M","8064-AU","8936","8939"];

const SD800:Array = ["8074-AA","8274-AA","8674-AA","8974-AA","8974-AB","8074-AB","8274-AB","8274-AC","8674-AB","8974-AB","8974-AC","APQ8084","MSM8974","MSM8992","MSM8994"];

const TEGRA:Array = ["TEGRA k1"];

Those are model numbers directly from Qualcomm and others -- thankfully there are only a handful of platform providers.

With "Class 3" devices reliably detected, I can toggle more advanced application features like high end transparency blend modes and higher quality rendering (It's a video creation app).

Sure, I could turn those things on for my baseline devices. But it makes them run slower (poor UX) and increases the chances for a memory related crash (almost a guaranteed negative review).

I like this solution because it grows with my app. When the next generation of hardware is released, I simply add the model numbers to an array and create a "Class 4". Then I can implement features that will only run on Class 4 devices, and eventually move my baseline to "Class 3".

So while the solution below is critical to ensuring only qualified "new enough" devices get to run my app, the secondary feature-specific adjustment is achieved using Performance Classes, based on the hardware platform variable which is consistently present in the android props.

--

There are roughly 5k devices that Google Play tracks.

I managed to get my "Supported" list down to about 2500 with the following settings in the manifest:

    <supports-screens
                android:smallScreens="false"
                android:normalScreens="true"
                android:largeScreens="true"
                android:xlargeScreens="true"
                android:requiresSmallestWidthDp="360"/>
             <compatible-screens>
                <!-- list the screens you support here -->
                <screen android:screenSize="normal" android:screenDensity="hdpi" />
                <screen android:screenSize="normal" android:screenDensity="xhdpi" />
                <screen android:screenSize="large" android:screenDensity="hdpi" />
                <screen android:screenSize="large" android:screenDensity="xhdpi" />
                <screen android:screenSize="xlarge" android:screenDensity="hdpi" />
                <screen android:screenSize="xlarge" android:screenDensity="xhdpi" />
                <screen android:screenSize="normal" android:screenDensity="480"/> 
                <screen android:screenSize="large" android:screenDensity="480"/>
                <screen android:screenSize="xlarge" android:screenDensity="480"/>
              </compatible-screens> 

I'm only showing the parts of the manifest that had a difference. For example, minsdk doesn't affect supported devices because in theory people can upgrade (in practice, not so much).

But even with these settings, I was still getting reports that people were having trouble with the app (in the form of 1 star reviews) so I found a way to cull it down further to 752:

                <supports-screens
                android:smallScreens="false"
                android:normalScreens="true"
                android:largeScreens="true"
                android:xlargeScreens="true"
                android:requiresSmallestWidthDp="360"/>
             <compatible-screens>
                <!-- list the screens you support here -->
                <screen android:screenSize="normal" android:screenDensity="xhdpi" />
                <screen android:screenSize="normal" android:screenDensity="480"/> 
                <screen android:screenSize="large" android:screenDensity="xhdpi" />
                <screen android:screenSize="large" android:screenDensity="480"/>
                <screen android:screenSize="xlarge" android:screenDensity="xhdpi" />
                <screen android:screenSize="xlarge" android:screenDensity="480"/>
              </compatible-screens> 
            <application>   

There ARE some devices out there that fit in to the categories I'm excluding (hdpi) and (small) ... but I've come to the conclusion that most of them are under powered.

By focusing on xhdpi, there's a better chance that the device is a newer device, thus having a faster processor and more memory.... thus having a better chance of being made in 2013+ :)

note: Google Play often doesn't update the "supported devices" list until after you publish to production. Even uploading to the "Beta" section doesn't always update the device list, making manifest iteration very time consuming and problematic. Just keep in mind that you can always roll a build back... so pushing to production to check the supported devices list isn't THAT bad.

Request to Google: You offer the ability to exclude devices that would otherwise be allowed by a manifest.
Please also offer the ability to INCLUDE devices that are not on a manifest. For "high end" apps, the selection set is much smaller, and it's far easier to include on a case by case, than exclude.

OTHER TIPS

Facebook has released a better option to my manual "performance class" approach.

It's called Year Class: https://github.com/facebook/device-year-class

Glad to see this issue being solved!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top