Devices:
Total duration:
Default Label:ReferenceApp
Version Code:1
Version Name:1.0
Package:com.amazonaws.devicefarm.android.referenceapp
Launch Activity:com.amazonaws.devicefarm.android.referenceapp.Activities.MainActivity
Use large heap:false
Debuggable:true
Min API Level:10
Target API Level:22
Max API Level:Undefined
Native CPU architectures:No
Screens:small normal large xlarge
Support Any Density:true
Densities:160 213 240 320 480 640
Locale:--_-- ca da fa ja nb de af bg th fi hi vi sk uk el nl pl sl tl am in ko ro ar fr hr sr tr cs es it lt pt hu ru zu lv sv iw sw fr-CA lo-LA en-GB bn-BD et-EE ka-GE ky-KG km-KH zh-HK si-LK mk-MK ur-PK hy-AM my-MM zh-CN ta-IN te-IN ml-IN en-IN kn-IN mr-IN mn-MN ne-NP pt-BR gl-ES eu-ES is-IS es-US pt-PT en-AU zh-TW ms-MY kk-KZ uz-UZ
android.permission.INTERNET
Allows the app to create network sockets and use custom network protocols. The browser and other applications provide means to send data to the internet, so this permission is not required to send data to the internet.
android.permission.CAMERA
Allows the app to take pictures and videos with the camera. This permission allows the app to use the camera at any time without your confirmation.
android.permission.ACCESS_WIFI_STATE
Allows the app to view information about Wi-Fi networking, such as whether Wi-Fi is enabled and name of connected Wi-Fi devices.
android.permission.ACCESS_NETWORK_STATE
Allows the app to view information about network connections such as which networks exist and are connected.
android.permission.CHANGE_WIFI_STATE
Allows the app to connect to and disconnect from Wi-Fi access points and to make changes to device configuration for Wi-Fi networks.
android.permission.ACCESS_FINE_LOCATION
Allows the app to get your precise location using the Global Positioning System (GPS) or network location sources such as cell towers and Wi-Fi. These location services must be turned on and available to your device for the app to use them. Apps may use this to determine where you are, and may consume additional battery power.
android.permission.BLUETOOTH
Allows the app to view the configuration of the Bluetooth on the phone, and to make and accept connections with paired devices.
android.permission.NFC
Allows the app to communicate with Near Field Communication (NFC) tags, cards, and readers.
android.permission.WRITE_EXTERNAL_STORAGE
Allows the app to write to the SD card.
android.permission.ACCESS_COARSE_LOCATION
Allows the app to get your approximate location. This location is derived by location services using network location sources such as cell towers and Wi-Fi. These location services must be turned on and available to your device for the app to use them. Apps may use this to determine approximately where you are.
android.permission.READ_EXTERNAL_STORAGE
Allows the app to read the contents of your SD card.
Not Found
Not Found
Android Activities are one of the most important part of application's overall lifecycle. The way activities are launched and how developers manage all them together is a fundamental part of the platform's application model.
In order to improve performance, developers should try to provide interface to users avoiding create several activities and consuming resources when is not needed.
Creating multiple activities causes Android to put them into the 'Back Stack' in order to save states such as text form, scroll position and other data. Multiple tasks can be held in the background at once. However, if the user is running many background tasks at the same time, the system might begin destroying background activities in order to recover memory, causing the activity states to be lost.
All non-trivial Android applications are made up of a number of different functional screens and hence multiple activities. Although multiple screens allows us to build complex applications, they also require careful management. In particular, developers need to deal with activities that are no longer visible since Android OS will place them into the background and may terminate activities that are not used for a period of time. The use of multiple activities also requires us to think about the interaction and navigation model that the user will experience.
Layouts are a key part of Android applications that directly affect the user experience. If poorly implemented, your layout can lead to a memory hungry application with slow UIs.
It is a common misconception that using the basic layout structures leads to the most efficient layouts. However, each widget and layout you add to your application requires initialization, layout, and drawing.
External library code is often not written for mobile environments and can be inefficient when used for work on a mobile client. At the very least, when you decide to use an external library, you should assume you are taking on a significant porting and maintenance burden to optimize the library for mobile. Plan for that work up-front and analyze the library in terms of code size and RAM footprint before deciding to use it at all.
Deprecated libraries shown in this section means that you are probably using libraries that are not up to date. In the other hand, abandoned ones, are libraries without support or pending bugs time ago. Usually, library updates are important in order to improve security, performance, compatibility & bug fixes.
When building an application, it's important to consider exactly what your graphical demands will be. Varying graphical tasks are best accomplished with varying techniques. For example, graphics and animations for a rather static application should be implemented much differently than graphics and animations for an interactive game. No matter what type of application it is, there are certain situations that affect the user experience (response rate, fluency, use of resources, battery etc.). Times drawn reflect possibly some things are not performing in the best possible shape for the type of service you want to provide with this.
To achieve fluid rendering (60 fps) each frame must be completed in less than 16ms. If not, application creates a disruption in the animation and sometimes it 'freeze'. Also, elevated drawing to the screen needs high CPU and/or GPU usage in order to maintain a constant rate, causing battery drain.
Device | Value |
---|---|
Samsung SM-A750FN (8.0.0): | 2 frames |
Samsung Galaxy Note 4 (SM-N910A) (5.0.1): | 1 frames |
Moto G4 Plus (XT1644) (7.0): | 1 frames |
Device | Value |
---|---|
Samsung SM-A750FN (8.0.0): | 35 ms |
Samsung Galaxy Note 4 (SM-N910A) (5.0.1): | 29 ms |
Moto G4 Plus (XT1644) (7.0): | 29 ms |
Video - Rendering Performance 101
Video - Perf Primer : CPU, GPU and your Android game
Video - Make your Android UI Fast and Efficient
Training - Improving Layout Performance
Video - Tool - Profile GPU Rendering
Blog - Android Performance Case Study: Falcon Pro
Video - Android UI and the GPU
Video - Writing zippy Android apps
Video - Understanding Overdraw
Video - Building High-Performance Applications
Video - Accelerated Android Rendering
Using the wireless radio to transfer data is potentially one of your app's most significant sources of extra fees, poor user experience and battery drain. To minimize the associated effects with network activity, it's important that you understand how your connectivity model will affect the underlying radio hardware.
If your application performs a lot of network operations, you should provide user settings that allow users to control your app's data habits, such as how often your app syncs data, whether to perform uploads/downloads only when on Wi-Fi, whether to use data while roaming, and so on.
Device | Value |
---|---|
Samsung SM-A750FN (8.0.0): | 64373 kB |
Samsung Galaxy Note 4 (SM-N910A) (5.0.1): | 729 kB |
Samsung Galaxy S6 (SM-G920T) (6.0.1): | 194 kB |
Moto G4 Plus (XT1644) (7.0): | 522 kB |
Samsung SM-T860 (9): | 49166 kB |
Device | Value |
---|---|
Samsung SM-A750FN (8.0.0): | 6960 kB |
Samsung Galaxy Note 4 (SM-N910A) (5.0.1): | 712 kB |
Samsung Galaxy S6 (SM-G920T) (6.0.1): | 183 kB |
Moto G4 Plus (XT1644) (7.0): | 520 kB |
Samsung SM-T860 (9): | 3562 kB |
The CPU is the unit responsible for carrying out all instructions of an application and all the necessary instructions for running different subsystems that maintain running the Android OS (multimedia, audio, render, etc.)
When the CPU usage is high, the user may experience sluggishness or higher battery usage (among some other symptoms). Since the CPU usage is a shared resource, abuse of CPU usage may prevent other running services work correctly, affecting the user experience as the proper functioning of Android (and the applications that run there). With higher levels of instructions, the CPU increases its speed with a consequent increase in use of voltage that causes the battery to drain faster
Random-access memory (RAM) is one of the most valuable resource in any software development environment, but it's even more valuable on several mobile operating system where physical memory is constrained.
To maintain a functional multi-tasking environment, Android sets a fixed limit on the Dalvik heap size for each app. The exact Dalvik heap size limit varies across devices, based on how much RAM the device has available overall. If your app has reached the heap capacity and tries to allocate more memory, it will receive an OutOfMemoryError.
IMPORTANT:
- Retaining memory that the app doesn't need can cause out of memory (OOM) exceptions or constraining the system's overall performance. So, as the system runs low on memory, it may kill processes in the LRU cache beginning with the process least recently used, but also giving some consideration toward which processes are most memory intensive.
TO CONSIDER:
- On Android 2.3.3 (API level 10) and lower, the backing pixel data for a bitmap is stored in native memory. It is separate from the bitmap itself, which is stored in the Dalvik heap.
- If your application requires more memory usage, you may want to consider using the largeHeap property available from Android 3.x.
Device | Value |
---|---|
Samsung SM-A750FN (8.0.0): | 95 MB |
Samsung Galaxy Note 4 (SM-N910A) (5.0.1): | 142 MB |
Samsung Galaxy S6 (SM-G920T) (6.0.1): | 82 MB |
Moto G4 Plus (XT1644) (7.0): | 31 MB |
Samsung SM-T860 (9): | 112 MB |
An application typically crashes when it performs an operation which is not allowed by the operating system. The operating system then triggers an exception or signal in the application.
An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions. A exception contains a snapshot of the execution stack of its thread at the time it was created. It can also contain a message string that gives more information about the error.
If your app stops responding, users get a dialog that allows them to wait or close the app. When these dialogs appear, they're known as 'Application not responding' errors or ANRs. Android will display the ANR dialog when it detects one of the following conditions:
No response to an input event (such as key press or screen touch events) within 5 seconds.
A BroadcastReceiver hasn't finished executing within 10 seconds.
When your app stops responding (ANR) Android generates dump files containing CPU and Threads information. This enables devs to identify CPU usage on each process at the moment that the app freezes and provides a snapshot containing threads information (thread, mutex and stack information).
Since battery is one of the top appreciated resources by users in their phones and tablets, developers should take care about battery consumption and need to know key-factors involved in battery drain.
High CPU usage means more frequency and more power needed to feed battery. Bad image rendering with high GPU or CPU usage, sensor usage and tracking location are also relevant factors to improve power consumption. More often, when using wireless radio to transfer data, the way to do it and how often your app uses radio is critical to minimize power consumption.
Video - Battery Drain and Networking
Video - Understanding Battery Drain on Android
Training - Optimizing Battery Life
Video - Battery Drain and WakeLocks
Training - Optimizing Downloads for Efficient Network Access
Training - Transferring Data Without Draining the Battery
Book - Optimizing Battery Life – Page 177:
Android version:
Manufacturer:
Model:
CPU Architecture:
Dalvik heap size limit:
Dalvik large heap size limit:
Screen orientation:
Screen resolution:
Layout size:
Display density:
OpenGL ES:
APK
Install
Test Run
Uninstall
Duration:
No data was recorded.
No data was recorded.
No data was recorded.
No data was recorded.
No data was recorded.
No data was recorded.
No data was recorded.