With frequent updates and releases, Google Play now requires all new apps to target a recent Android API level - set to API level 26 (Android 8.0 - Oreo) or higher. So how does updates like these impact your test coverage? Are you able to analyze these information and identify the impacted areas and devices that can help you optimize your device and test coverage? Find out the details about this in this blog: https://www.pcloudy.com/how-to-analyze-data-to-predict-your-optimum-device-test-coverage/?utm_source=linkedin&utm_medium=post&utm_content=68614421&utm_campaign=android_ios&gclid=EAIaIQobChMI-eDJ7-Tu3QIVRw4rCh1WyQ3yEAAYASAAEgLyRPD_BwE For more details visit www.pcloudy.com

1. How to optimize Device and Test Coverage?

2. Agenda
The ever growing device fragmentation
and its effect
Traditional methods to devise device &
test coverage
What’s the surprise @ pCloudy ?

3. 24,093 distinct Android devices

4. The ever-growing versions of Android
Oreo moves up to 21.5 percent from 19.2 percent.
This along with a small drop in Marshmallow’s
numbers brings last year’s version of Android to
just 6.7 percent below Nougat.

5. Let’s do some math!
• 16 device display categories
• 20 different common resolutions
• 15 Android versions
• 400 Android device Manufacturers
• 4 Major cellular networks
• 16 x 20 x 15 x 400 x 4 = 768000 permutations
Is it feasible?

6. Devising the
right device
matrix
Based on
Market
Penetration
By using
Purchased
data
By using
Analytics
Based on
Device
Diversity
How do you find your right device coverage?

7. Selecting Devices based on Market
Penetration
Determine the set of devices with your target operating system that will have the highest
occurrence of accessing your application.
For Example-
>
What will you prioritize if you’ve more number of Samsung & Xiomi users than iPhone users?

8. Optimizing coverage through Device Planner

9. Market Share Approach for Consumer Apps
Pros
You can typically gather
approximate market share
data and utilize it to prioritize
your test device list
You choose devices with the
highest market share and test
on as many as you have time
and resources for.
Cons
You could be missing a whole
class of devices that are less
popular but might hold a
significant portion of the
market.
You could be wasting
resources testing on two
devices that are very similar
Purchased Data
Analytics
Source:

10. Selecting Devices based on Device Diversity
 Quad Core or above
CPU
 RAM >=3 GB
 Display >= 5“
 Retina, Full-HD
display
 Latest OS Version
 Dual Core CPU
 RAM <=1 GB
 Screen size <= 5“
 No Retina or Full HD
Display
 OS less than 1 year
 Single Core CPU
 RAM up to 1GB
 Display size <4”
 Low screen resolution
 Older OS
 older browser
High End Devices Medium Range Devices Slow Devices
A B C

11. Group
Google Pixel 3 OnePlus 6 Samsung S9+Vivo 9 Oppo F7
RAM
CPU
Display
OS
4GB
5.7" 5.5"
8GB
5.8"
4GB
6.3"
4GB
6.3"
Android 8
4GB
Octa
core
Octa
core
Quad
core
Octa
core
Quad
core
Android 9 Android 8 Android 8 Android 9
A

12. Group B
Galaxy CoreI8262 Sony Xperia
SL(LT26II)
Micromax
Canvas Superfone
Asus Zenfone4 Oppo Joy
RAM
CPU
Display
OS
1GB
4.3" 4.3"
1GB
5.0"
1GB
4.0"
1GB
4.0"
Android
4.4
1GB
Dual
core
Dual
core
Dual
core
Dual
core
Dual
Core
Android
4.1.2
Android
4.0.4
Android
4.0.4
Android
4.4

13. Group C
Sony Xperia Tipo HTC A310E Explorer LG Optimus Net
Samsung Galaxy Chat
RAM
Processor
Display
OS
512 MB
850
MHz
3.2"
Android
4.0
Android
2.3
Android
4.0
3.0"
512 MB
3.2"
850
MHz
650
MHz
512 MB512 MB
3.2"
800
MHz
Android
2.3

14. Optimizing your test & device coverage the pCloudy way!

15. Terminologies
Manifest File: Every project in Android includes a manifest file stored in the root directory
of its project hierarchy.
What information do you get here?
•Key information about the app without having to read other files in the package or run
the application.
•Defines which components of the application will be accessible externally to other apps,
and how those components interact with other apps.
•Declares which components and resources (icons, text strings, etc.) to use in which cases,
in particular with relation to other apps.

16. Terminologies
Target API Level: The Target Framework (also known as compileSdkVersion ) is the specific Android
framework version (API level) that your app is compiled for at build time.
• This setting specifies what APIs your app expects to use when it runs.
• It has no effect on which APIs are actually available to your app when it is installed
Android versions - Each release of Android goes by multiple names:
• The Android version, such as Android 9.0
• A code (or dessert) name, such as Pie
• A corresponding API level, such as API level 28

17. Why bugs occur?

18. Why bugs occur?
Android Apps
Application Framework
Inter-Process Communication Proxies
Android System Services and Mangers
Hardware Abstraction Layer
Linux Kennel (With Hardware Drivers)
]
]
Higher Level
System
Lower Level
System

19. What does our analysis say?
Type Root Cause Percentage of Issues Issue Examples
Device -
Specific
Problematic Driver
Implementation
56%
OS Customization 36%
Peculiar hardware
composition
20%
Non-device
Specific
Android Platform API
evolution
67%
Original Android System
bugs
12%

20. What does our analysis say?

21. • Let’s not test…let’s predict…

22. The path ahead!
• The digital age force us to test smarter! Optimizing test & device
coverage is the first step.
• Effective use of Data Analysis to take testing to the next level
• pCloudy is at the forefront of innovation to keep you ahead

23. Q&Ainfo@pcloudy.com
avinash.tiwari@pcloudy.com