Allows the app to have itself started as soon as the system has finished booting. This can make it take longer to start the phone and allow the app to slow down the overall phone by always running.
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.GET_ACCOUNTS Allows the app to get the list of accounts known by the phone. This may include any accounts created by applications you have installed.
android.permission.USE_CREDENTIALS Allows the app to request authentication tokens.
android.permission.ACCESS_NETWORK_STATE Allows the app to view information about network connections such as which networks exist and are connected.
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.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.WRITE_EXTERNAL_STORAGE Allows the app to write to the SD card.
android.permission.READ_SYNC_SETTINGS Allows the app to read the sync settings for an account. For example, this can determine whether the People app is synced with an account.
android.permission.READ_SYNC_STATS Allows an app to read the sync stats for an account, including the history of sync events and how much data is synced.
android.permission.VIBRATE Allows the app to control the vibrator.
android.permission.NFC Allows the app to communicate with Near Field Communication (NFC) tags, cards, and readers.
com.google.android.providers.gsf.permission.READ_GSERVICES Allows this app to read Google service configuration data.
android.permission.READ_CALENDAR Allows the app to read all calendar events stored on your phone, including those of friends or co-workers. This may allow the app to share or save your calendar data, regardless of confidentiality or sensitivity.
android.permission.WRITE_CALENDAR Allows the app to add, remove, change events that you can modify on your phone, including those of friends or co-workers. This may allow the app to send messages that appear to come from calendar owners, or modify events without the owners' knowledge.
android.permission.WRITE_SYNC_SETTINGS Allows an app to modify the sync settings for an account. For example, this can be used to enable sync of the People app with an account.
android.permission.WAKE_LOCK Allows the app to prevent the phone from going to sleep.
com.google.android.c2dm.permission.RECEIVE Allows apps to accept cloud to device messages sent by the app's service. Using this service will incur data usage. Malicious apps could cause excess data usage.
com.google.samples.apps.iosched.permission.C2D_MESSAGE Unknown / User defined
com.google.samples.apps.iosched.permission.MAPS_RECEIVE Unknown / User defined
android.permission.READ_EXTERNAL_STORAGE Allows the app to read the contents of your SD card.
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.
Activities amount
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.
Activities: 16
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
16
Samsung Galaxy S III (GT-I9300) (4.3):
16
Acer Iconia A1-810 7.9" (4.2.2):
16
Google Nexus 10 (5.1.1):
16
LG G2 (LS980) (5.0.2):
16
Google Nexus 4 (5.0.1):
16
HTC One (M8) (4.4.2):
16
Google Nexus 7 (5.0.2):
16
Activities stack
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.
Activities on Back Stack: 3
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
2
Samsung Galaxy S III (GT-I9300) (4.3):
3
Acer Iconia A1-810 7.9" (4.2.2):
1
Google Nexus 10 (5.1.1):
1
LG G2 (LS980) (5.0.2):
1
Google Nexus 4 (5.0.1):
1
HTC One (M8) (4.4.2):
0
Google Nexus 7 (5.0.2):
1
Layout
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.
UI controls
Too many controls on the screen57(Soft Limit: 50 Hard Limit: 100)
It seems that some activities has a significant amount of UI controls. It is recommended to take a look at UI design and consider write a custom ViewGroup.
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.
Nested layouts level is medium15(Soft Limit: 10 Hard Limit: 20)
Take a look at nested layout considering for example that Linear Layouts using weight parameter requires the child to be measured twice: Initialization, layout and drawing become slower.
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
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.
Deprecated library: Google Cloud Messaging (legacy)
An Android application is a single installable unit that can be started and used independently of other applications.
Every application could have one application class which is instantiated as soon as the application starts and it is the last component stopped during shutdown.
Your app must declare its components in AndroidManifest.xml ('manifest' file), There are four different types of components: Activities, Services, Content providers and Broadcast receivers. Each type serves different purposes and has its own lifecycle that defines how the component is created and destroyed. When the system start a component, it starts the process for that app (if it's not already running) and instantiates the classes needed for the component.
Launching time
Memory usage and launch time are in the top of developer's performance concerns. In the other hand, users expect you app to load in 3 seconds. If your app doesn't launch fast enough, you may lose them.
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.
Render Time
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.
Maximum lag in render frame is high (jank)30frames(Soft Limit: 10frames Hard Limit: 20frames)
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
9frames
Samsung Galaxy S III (GT-I9300) (4.3):
5frames
Acer Iconia A1-810 7.9" (4.2.2):
30frames
Google Nexus 10 (5.1.1):
1frames
LG G2 (LS980) (5.0.2):
0frames
Google Nexus 4 (5.0.1):
1frames
HTC One (M8) (4.4.2):
1frames
Google Nexus 7 (5.0.2):
2frames
Drawing time is too high506ms(Soft Limit: 160ms Hard Limit: 320ms)
When render time (CPU) is elevated your application misses opportunity to draw new frames, probably freezing screen and consuming resources. For detailed drawing times and rates you should take a look at 'Render Time', 'FPS' and 'Render Lag' charts in each execution.
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.)
CPU usage
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 incorrectly, 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
Maximum CPU usage is medium.78%(Soft Limit: 70% Hard Limit: 90%)
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.
Memory usage
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.
Android
API Level
Bitmap Pixel Data Alloc*
Default Heap Size Limit
Large Heap Size Limit**
Android 1.x - Alpha / Beta
1 to 7
Native Heap
16MB
NA
Android 2.2.x - Froyo
8
Native Heap
24MB
NA
Android 2.3.x - Gingerbread
9 to 10
Native Heap
32MB
NA
Android 3.x - Honeycomb
11 to 13
Dalvik Heap
48MB
128MB
Android 4.0.x - Ice Cream Sandwich
14 to 15
Dalvik Heap
64MB
128MB
Android 4.1.x/4.2.x - Jelly Bean
16 to 17
Dalvik Heap
128MB
128MB
Android 4.3.x/4.4.x- Jelly Bean/KitKat
18 to 19
Dalvik Heap
128MB
256MB
Android 5.x- Lollipop
20 to 22
Dalvik Heap
128MB
256MB
* 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. ** Only valid if the option "largeHeap" is enabled (available from Android 3.x - API Level 11).
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.
GC Explicit1(Soft Limit: 1 Hard Limit: 100)
Calling expicit garbage collection is not recomended and a bad practice in Android, developers should trust in Dalvik algorithms for garbage collection and avoid explicit collection, since VM may just ignore the request and decide to do anything.
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
1
Samsung Galaxy S III (GT-I9300) (4.3):
0
Acer Iconia A1-810 7.9" (4.2.2):
0
Google Nexus 10 (5.1.1):
0
LG G2 (LS980) (5.0.2):
0
Google Nexus 4 (5.0.1):
0
HTC One (M8) (4.4.2):
0
Google Nexus 7 (5.0.2):
0
Market Limit: Average Heap (Dalvik) memory: 23MB
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
11MB
Samsung Galaxy S III (GT-I9300) (4.3):
18MB
Acer Iconia A1-810 7.9" (4.2.2):
7MB
Google Nexus 10 (5.1.1):
10MB
LG G2 (LS980) (5.0.2):
23MB
Google Nexus 4 (5.0.1):
20MB
HTC One (M8) (4.4.2):
6MB
Google Nexus 7 (5.0.2):
12MB
Market Limit: Maximum Heap (Dalvik) memory: 38MB
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
14MB
Samsung Galaxy S III (GT-I9300) (4.3):
38MB
Acer Iconia A1-810 7.9" (4.2.2):
10MB
Google Nexus 10 (5.1.1):
12MB
LG G2 (LS980) (5.0.2):
28MB
Google Nexus 4 (5.0.1):
34MB
HTC One (M8) (4.4.2):
11MB
Google Nexus 7 (5.0.2):
26MB
Device Limit: Maximum Heap (Dalvik) memory usage: 59%
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
21%
Samsung Galaxy S III (GT-I9300) (4.3):
59%
Acer Iconia A1-810 7.9" (4.2.2):
7%
Google Nexus 10 (5.1.1):
6%
LG G2 (LS980) (5.0.2):
10%
Google Nexus 4 (5.0.1):
17%
HTC One (M8) (4.4.2):
5%
Google Nexus 7 (5.0.2):
13%
Device Limit: Maximum Heap (Dalvik) memory usage after GC: 56%
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.
Network usage
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.
Medium level of downloaded data3024kB(Soft Limit: 3000kB Hard Limit: 10000kB)
In a short period of time, the application downloaded a total of 1629kB of data. This can affect user experience, cause battery drain as well as getting charged by some mobile networks.
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.
ANR Dump Logs
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).
ANR: None
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
None
Samsung Galaxy S III (GT-I9300) (4.3):
None
Acer Iconia A1-810 7.9" (4.2.2):
None
Google Nexus 10 (5.1.1):
None
LG G2 (LS980) (5.0.2):
None
Google Nexus 4 (5.0.1):
None
HTC One (M8) (4.4.2):
None
Google Nexus 7 (5.0.2):
None
Crash
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.
Exceptions
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.
Exception: None
Device
Value
Samsung Galaxy Note 10.1" (GT-N8013) (4.1.2):
None
Samsung Galaxy S III (GT-I9300) (4.3):
None
Acer Iconia A1-810 7.9" (4.2.2):
None
Google Nexus 10 (5.1.1):
None
LG G2 (LS980) (5.0.2):
None
Google Nexus 4 (5.0.1):
None
HTC One (M8) (4.4.2):
None
Google Nexus 7 (5.0.2):
None
Power usage is Medium
Power usage
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.