Universal quick replies could be coming to Android, thanks to MohammadAG

Quick replies are very convenient for passing back a brief message, however, unfortunately not all apps and OEMs support this helpful messaging feature. If you’re unfamiliar with the concept, rather than having to open up an app to reply to a message, quick replies empower users to respond directly using a box that accompanies a notification.

Enter MohammedAG, who has hastily responded to Reddit requests for a universal quick reply feature. Less than 24 hours after the concept appeared, the developer has already shown off a work in progress video of its Heads Up Quick Replies application.

The option for quick replies is already built within Android, but specific apps and OEMs have to choose to make use of it for their application. Hence some stock and third party SMS applications already support a similar feature, but it’s not automatically universally applied to all messaging apps. Quick Replies aims to accommodate virtually all messaging platforms.

Development plans to avoid the use of root access, meaning that, when it’s finished, a large number of Android handset owners should be able to make use of the app. KitKat and above will be supported and it will apparently work with any app that supports Wear voice replies, including Hangouts, Telegram, WhatsApp and Facebook Messenger, among others. Unfortunately, removing the stock heads up notification doesn’t seem to be possible without root, but the app is now running over the top of the default notification as a quick fix.

The app is not available to download just yet, as development is still ongoing. Hopefully we’ll see an alpha or beta build show up soon.

Ways to economically test your apps on a range of devices

There are literally thousands of different Android devices on the market today. Obtaining a devices matching every possible permutation of processor, RAM, screen size, screen resolution and Android version for all devices in the market today is a herculean (if not impossible) task. There are bugs that can get only be triggered on a given hardware or software configuration. For indie and small development teams, the ability to test a newly developed application on a wide variety of devices before app release as cheaply as possible is a major headache. To help you prioritize which device configurations to test on, check out this data set. It presents a snapshot of all devices that visited the Google Play Store over the previous seven day period. Read on for some of the methods available to economically test your apps (free and/or very cheap), along with a few pricier alternatives.

1. Android Virtual Device (AVD) Manager

The AVD manager is available to install as an Android Development Tools (ADT) plugin on Eclipse, or with a fresh install of Android Studio. While developing with Android Studio, you can view a graphical representation of your layout design across a wide range of devices. You can be certain that the final layout on a real device will be almost identical to that shown via the graphical view.

Also, using the AVD Manager, you can download and create virtual devices that mimic a wide range of possible device types and configurations, including RAM, screen size, screen resolution, Android version and more. You can then run your app on these emulated devices. These devices completely emulate the Android runtime, however, they will likely run slower than a physical android device. Having said that, the Android Emulator has improved in leaps and bounds, and now supports hardware acceleration on supported devices. With hardware acceleration, emulated devices run much faster, since they are using the actual computer hardware, rather than the previous all software method. For more information on configuring and managing your virtual devices with AVD Manager, visit the Android Developer site.

2. Genymotion

Genymotion bills itself as a fast and easy-to-use Android emulator, that is based on AOSP and comes with 20 pre-configured devices. Genymotion runs on Linux, OS X and Windows systems. Some features include:

• Resizable windows
• Copy paste between virtual device and host OS
• App installation using drag and drop
• Integration with both Android Studio and Eclipse
• 20 pre-configured devices
• Ability to create custom device configurations
• Supports Android versions: 2.3, 4.1, 4.2, 4.3, 4.4, 5.0, 5.1
• Provides sensor emulation: GPS, microphone, camera, battery, multi-touch, accelerometer
• Network quality and performance emulation

While there is a free version of Genymotion for private/personal use, most of the features listed above require a purchased/licensed version. At the time of writing, the cost is €24.99 per month per user, with a minimum duration of 12 months. Not cheap by any means. However, there is a special discount for indie developers (defined as private individuals or small companies with no more than two employees), with a cost of €8.25 monthly, also with a minimum duration of 12 months.

3. Crowd sourced testing

Rather than purchasing a large number of different devices, crowd sourced testing enables developers leverage potential users own devices for testing. This also has the advantage of exposing your app to users before being generally available to the public, as well as getting users to perform QA. Free crowd sourced testing options include the Google Play Store and Lean Testing.

Using the Google Play store, you can release an app as a beta or alpha test release, which means that only members of your test community can see and download your app. With this manner of release, you can leverage your existing social network’s available devices as tests for your app. Members of your test community can download and test your app on all of their devices. This is advantageous in many ways, not least of which is that you are testing your app from the same dashboard that will be used for final deployment. Also, you do not need to include any new APIs. With alpha and beta test versions, you can include every feature intended for the final app, and be reasonably confident the performance will be identical to the production version. The major disadvantage of this is that members of your test group must also be members of your Google+ test community. Not really a disadvantage since users already have a Google+ account if they use the Play Store.

Lean Testing is a community, where you can create an account for your organization. Within this account, you can create multiple projects, invite other users to either the organization as a whole, or to specific projects, and also assign specific roles and permissions to the invited users. Your users can then report, update and delete bugs encountered while using your app. Lean Testing can be used for other types of testing, including iOS, website, etc. For now, Lean Testing is free to use, but according to the FAQ, it won’t be free forever. You might want to check it out before it becomes a paid service.

4. Buy used devices

Somehow, this is an often overlooked method of getting access to a wide range of devices. You, and your team, should always be on the lookout for devices being sold cheaply. Two year old flagships can be bought for less than a third of the initial retail price, and mid-range and low-end devices can be purchased at rock bottom prices. Considering that the object is to test on as wide a range of devices as possible, a steady purchase of used devices would ensure that in a few years, your device list would include multiple OS versions, screen sizes and different levels of software update. In other words, it would closely resemble real world user devices.

5. Paid Options

Of course, the term “economically viable” means different things to different people. For some teams, completely free options are the only economically viable choice, while others can have thousands of dollars available for testing equipment. Compare and contrast the paid options below. You might find one that matches your expected feature list and budget constraints:

• Applause
• AppThwack
• StartupLift
• Testdroid
• TestFairy
• TestObject

Android device configurations is like the Wild West of the mobile world. From screen sizes to form factors to OS versions. Fragmentation has been a major issue with Android right from the beginning, but it is also one of its major strengths and selling points. For app developers, however, this presents quite a challenge.
Emulation testing can be used to catch many possible layout issues, however, there must be some hands-on, physical device testing with as many devices and device types as possible.

How do you economically test your app? Did we leave your favorite free/cheap testing method out? Help your fellow developers out, spread the word and share in the comments below.

Android Developer Newsletter

Do you want to know more? Subscribe to our Android Developer Newsletter. Just type in your email address below to get all the top developer news, tips & links once a week in your inbox:Email:
PS. No spam, ever. Your email address will only ever be used for Android Dev Weekly.

Xiaomi Mi 4i is on open sale on Flipkart until tomorrow

India’s “Online Megastore” is giving customers a chance to buy Xiaomi’s new Mi 4i smartphone without having to go through the lottery of flash sales.

Launched on April 23 as an Indian exclusive (at least for now), the Xiaomi Mi 4i offers some of the best bang for the money we’ve seen on any device. Rs. 12,999, the equivalent of about $200, brings you a 5-inch Full HD display, a Snapdragon 615 octo-core processor, 2GB of RAM, 16GB of storage, a 13MP f/2.0 rear camera with dual-tone LED flash, and a 5.1MP f/1.8 front camera, and a 3,120 mAh battery. By any measure, this is a great device and it’s much cheaper than phones with similar specs and features.

Until now, customers had to pre-register to buy a Mi 4i and be lucky/fast enough to snag one before stocks ran out. As part of its sales event, Flipkart is currently offering the Xiaomi Mi 4i on open sale for Rs. 12,999. The open sale will continue tomorrow as well. Flipkart is also offering an exchange option that could give you up to Rs. 9000 if you bring in a Xiaomi device.

Fact or Fiction: Android apps only use one CPU core

We have had multi-core processors in our PCs for over a decade, and today they are considered the norm. At first it was dual-core, then quad-core, and today companies like Intel and AMD offer high end desktop processors with 6 or even 8 cores. Smartphone processors have a similar history. Dual-core energy efficient processors from ARM arrived about 5 years ago, and since then we have seen the release of ARM based 4, 6 and 8 core processors. However there is one big difference between the 6 and 8 core desktop processors from Intel and AMD and the 6, and 8 core processors based on the ARM architecture – most ARM based processors with more than 4 cores use at least two different core designs.

While there are some exceptions, in general an 8 core ARM based processor uses a system known as Heterogeneous Multi-Processing (HMP) which means that not all the cores are equal (hence Heterogeneous). In a modern 64-bit processor this would mean that a cluster of Cortex-A57 or Cortex-A72 cores would be used in conjunction with a cluster of Cortex-A53 cores. The A72 is a high performance core, while the A53 has greater energy efficiency. This arrangement is known as big.LITTLE where big processor cores (Cortex-A72) are combined with LITTLE processor cores (Cortex-A53). This is very different to the 6 or 8 core desktop processors that we see from Intel and AMD, as on the desktop power consumption isn’t as critical as it is on mobile.

The key thing to remember is that an octa-core big.LITTLE processor has eight cores for power efficiency, not for performance.

When multi-core processors first came to the desktop, a lot of questions were raised about the benefits of a dual-core processor over a single core processor. Was a dual-core 1.6GHz processor “better” than a 3.2GHz single core processor, and so on. What about Windows? Could it utilize a dual-core processor to its maximum potential. What about games – aren’t they better on single-core processors? Don’t applications need to be written in a special way to use the extra cores? And so on.

Multi-processing primer

These are legitimate questions, and of course the same questions have been asked about multi-core processors in smartphones. Before we look at the question of multi-core processors and Android apps, let’s take a step back and look at multi-core technology in general.

Computers are very good a doing one thing. You want to calculate the first 100 million prime numbers? No problem, a computer can loop round and round all day crunching those numbers. But the moment you want a computer to do two things at once, like calculating those primes while running a GUI so you can also browse the web, then suddenly everything becomes a bit more difficult.

I don’t want to go too deep here, but basically there is a technique known as preemptive multi-tasking which allows the available CPU time to be split among multiple tasks. A “slice” of CPU time will be given to one task (a process) and then a slice to the next process, and so on. At the heart of operating systems like Linux, Windows, OS X, and Android is a bit of technology called a scheduler. Its job is to work out which process should receive the next slice of CPU time.

Schedulers can be written in different ways, on a server the scheduler might be tuned to give priority to tasks performing I/O (like writing to the disk, or reading from the network), whereas on a desktop the scheduler will be more concerned with keeping the GUI responsive.

When there is more than one core available the scheduler can give one process a slice of time on CPU0, while another process gets a slice of run-time on CPU1. This way a dual-core processor, together with the scheduler, can allow two things to happen at once. If you then add more cores, then more processes can run simultaneously.

You will have noticed that the scheduler is good at slicing up the CPU resources between different tasks like calculating primes, running the desktop, and using a web browser. However a single process like calculating primes can’t be split across multiple cores. Or can it?

Some tasks are sequential by nature. To make a cake you need to crack some eggs, add some flour, make the cake mix etc, and then at the end put it into the oven. You can’t put the cake tin into the oven until the cake mix is ready. So even if you had two chefs in a kitchen you can’t necessarily save time on one task. There are steps to be followed and the order can’t be broken. You can multi-task, in that while one chef is making the cake the other can prepare a salad, but tasks which have a predefined sequence can’t benefit from dual-core processors or even 12 core processors.

If you still hear people saying things like, ‘but a smartphone doesn’t need 8 cores’ then just throw your hands up in despair.

However not all tasks are like that. Many operations that a computer performs can be split into independent tasks. To do this the main process can create another process and farm out some of the work to it. For example, if you are using an algorithm to find prime numbers, that doesn’t rely on previous results (i.e. not a Sieve of Eratosthenes), then you could split the work in two. One process could check the first 50 million numbers and the second process could check the second 50 million. If you have a quad-core processor then you could split the work into four, and so on.

But for that to work the program needs to be written in a special way. In other words the program needs to be designed to split the workload into smaller chunks rather than doing it in one lump. There are various programming techniques for doing this, and you might have heard expressions like “single-threaded” and “multi-threaded.” These terms broadly mean programs which are written with just one executing program (single-threaded, all lumped together) or with individual tasks (threads) which can be independently scheduled to get time on the CPU. In short, a single-threaded program won’t benefit from running on a multi-core processor, whereas a multi-threaded program will.

OK, we are almost there, just one more thing before we look at Android. Depending on how an operating system has been written, some actions that a program performs can be multi-threaded by nature. Often the different bits of an OS are themselves independent tasks and when your program performs some I/O or maybe draws something to the screen that action is actually carried out by another process on the system. By using of what is known as “non-blocking calls” it is possible to get a level of multi-threading into a program without actually specifically creating threads.

This is an important aspect for Android. One of the system level tasks in Android’s architecture is the SurfaceFlinger. It is a core part of the way Android sends graphics to the display. It is a separate task that needs to be scheduled and given a slice of CPU time. What this means is that certain graphic operations need another process to run before they are complete.

Android

Because of processes like the SurfaceFlinger, Android benefits from multi-core processors without a specific app actually being multi-threaded by design. Also because there are lots of things always happening in the background, like sync and widgets, then Android as a whole benefits from using a multi-core processor. As you would expect Android has the ability to create multi-threaded apps. For more information on this see the Processes and Threads section in the Android documentation. There is also some multi-threaded examples from Google, and Qualcomm have an interesting article on programming Android apps for multi-core processors.

However the question still remains, are the majority of Android apps single-threaded, and as such only use one CPU core? This is an important question because if the majority Android apps are single-threaded then you could have a smartphone with monster multi-core processor, but in reality it will perform the same as a dual-core processor!

In all my tests I did not see any real-world apps that used all 8 cores at 100%, and that is how it should be.

There seems to be some confusion about the difference between quad-core and octa-core processors. In the desktop and server world octa-core processors are built using the same core design replicated across the chip. However for the majority of ARM based octa-core processors there are high performance cores and core with better energy efficiency. The idea is that the more energy efficient cores are used for more menial tasks while the high performance cores are used for the heavy lifting. However it is also true that all the cores can be used simultaneously, like on a desktop processor.

The key thing to remember is that an octa-core big.LITTLE processor has eight cores for power efficiency, not for performance.

Testing

Android apps are able to take advantage of multi-core processors and big.LITTLE allows the scheduler to pick the best core combination for the current workload.

It is possible to get data from Android about how much it has used it core in the processor. For those who are technically minded, the information can be found in the /proc/stat file. I wrote a tool which grabs the per core usage information from Android while an app is running. To increase the efficiency, and lessen the performance hit of the monitoring, the data is only collect while the test app is active. The analysis of the collected data is done “off-line.”

Using this tool, which doesn’t have a name yet, I ran a series of different types of apps (gaming, web browsing etc) on a phone with a quad-core Qualcomm Snapdragon 801 processor and again on a phone with an octa-core Qualcomm Snapdragon 615 processor. I have collated the data from these test runs and with the help of Android Authority’s Robert Triggs, I have generated some graphs which show how the processor is being used.

Let’s start with an easy use case. Here is a graph of how the cores in the Snapdragon 801 are used when browsing the web using Chrome:

Chrome – Active cores on a quad-core phone.

The graph shows how many cores are being used by Android and the web browser. It doesn’t show how much the core is being used (that comes in a moment) but it shows if the core is being utilized at all. If Chrome was single-threaded then you would expect to see one or two cores in use and maybe a blip up to 3 or 4 cores occasionally. However we don’t see that. What we see is the opposite, four cores are being used and it occasionally dips down to two. In the browsing test I didn’t spend time reading the pages that loaded, as that would have resulted in no CPU use. However I waited until the page was loaded and rendered, and then I moved on to the next page.

Here is a graph showing how much each core was utilized. This is an averaged-out graph (as the real one is a scary scrawl of lines). This means that the peak usages are shown as less. For example the peak on this graph is just over 90%, however the raw data shows that some of the cores hit 100% multiple times during the test run. However it still gives us a good representation of what was happening.

Chrome – Core usage on quad-core phone.

So what about an octa-core? Will it show the same pattern? As you can see from the graph below, no it doesn’t. Seven cores are consistently being used with the occasional spike to 8, and a few times when it dips to 6 and 4 cores.

Chrome – Active cores on a octa-core phone.

Also the averaged core usage graph shows that the scheduler behaved quite differently since the Snapdragon 615 is a big.LITTLE processor.

Chrome – Core usage on octa-core phone.

You can see that there are two or three cores which run more than the others, however all the cores are being utilized in some way or another. What we are seeing is how the big.LITTLE architecture is able to swap threads from one core to another depending on the load. Remember the extra cores are here for energy efficiency, not performance.

It is a myth that Android apps only use one core.

However I think we can safely say that it is a myth that Android apps only use one core. Of course this is to be expected since Chrome is designed to be multi-threaded, on Android as well as on PCs.

Other apps

So that was Chrome, an app that is designed to be multi-threaded, what about other apps? I ran some tests on other apps and briefly this is what I discovered:

• Gmail – On a quad-core phone the core usage was evenly split between 2 and 4 cores. However average core utilization never went above 50% which is to be expected as this is a relatively light app. On an octa-core processor the core usage bounced between 4 and 8 cores, but with a much lower average core utilization of less than 35%.
• YouTube – On a quad-core phone only 2 cores were used, and on average at less than 50% utilization. On an octa-core phone YouTube mainly used 4 cores with the occasional spike to 6, and drop to 3. However the average core utilization was just 30%. Interestingly the scheduler heavily favored the big cores and the LITTLE cores were hardly used.
• Riptide GP2 – On a phone with a quad-core Qualcomm processor this game used two cores most of the time with the other two cores doing very little. However on an phone with an octa-core processor, between six and seven cores where used consistently, however most of the work was done by just three of those cores.
• Templerun 2 – This game probably exhibits the single-threaded problem more than the other apps I tested. On an octa-core phone the game used between 4 and 5 cores consistently and peaked at 7 cores. However really only one core was doing all the hard work. On a quad-core Qualcomm Snapdragon 801 phone, two cores shared the work fairly evenly, and two cores did very little. On a quad-core MediaTek phone all four cores shared the workload. This highlights how a different scheduler and different core designs can drastically alter the way the CPU is used.

Here is a selection of graphs for you to peruse. I have included a graph showing the octa-core phone idle, as a base reference:

#gallery-1
margin: auto;

#gallery-1 .gallery-item
float: left;
margin-top: 10px;
text-align: center;
width: 25%;

#gallery-1 img
border: 2px solid #cfcfcf;

#gallery-1 .gallery-caption
margin-left: 0;

/* see gallery_shortcode() in wp-includes/media.php */

One interesting app was AnTuTu. I ran the app on the octa-core phone and this is what I saw:

AnTuTu running on an octa-core phone.

As you can see, the latter part of the test completely maxes out all the CPU cores. It is clear that the benchmark is artificially creating a high workload, and since nearly all the cores are running at full speed then SoCs with more cores will score better for that part of the test. I never saw this kind of workload on any normal apps.

In one way it is the benchmarks which are artificially inflating the performance benefits of octa-core phones (rather than the power efficiency advantages). For a more comprehensive look at benchmarking check out Beware of the benchmarks, how to know what to look for.

Why are light apps using 8 cores?

If you look at an app like Gmail you will notice and interesting phenomenon. On a quad-core phone the core usage was evenly split between 2 and 4 cores, but on an octa-core phone the app used between 4 and 8 cores. How come Gmail can run on 2 to 4 cores on a quad-core phone but needs at least four cores on an octa-core phone? That doesn’t make sense!

The key again is to remember that on big.LITTLE phones not all the cores are equal. What we are actually seeing is how the scheduler is using the LITTLE cores then as the workload increases the big core are brought into play. For a while there is a small amount of crossover and then the LITTLE cores go to sleep. Then when the workload decreases the opposite happens. Of course this is all happening very fast, thousands of times per second. Look at this graph which shows the utilization of big vs LITTLE cores during my testing of Epic Citadel:

Epic Citadel – big vs LITTLE core usage on octa-core phone.

Notice how at first the big cores are being used and the LITTLE cores are inactive. Then, at around the 12 second mark, the big cores start to be used less and the LITTLE cores spring to life. At the 20 second mark the big cores increase their activity again and the LITTLE cores go back down to almost zero usage. You can see this again at the 30 second mark, the 45 second mark, and at the 52 second mark.

At these points the number of cores being used fluctuates. For example, in the first 10 seconds only 3 or 4 cores are being used (big cores), and then at the 12 second mark the core usage peaks at 6 and then drops again to 4, and so on.

This is big.LITTLE in action. A big.LITTLE processor isn’t designed like the octa-core processors for PCs. The extra cores allows the scheduler to pick the right core for the right job. In all my tests I did not see any real-world apps that used all 8 cores at 100%, and that is how it should be.

Caveats and wrap-up

The first thing to underline is that these tests do not benchmark the performance of the phones. My testing only shows if Android apps run across multiple cores. The advantages or disadvantages of running over multiple core, or running on a big.LITTLE SoC, are not covered. Neither are the benefits or drawbacks of running parts of an app on two cores at 25% utilization, rather than on one core at 50%, and so on.

Secondly, I haven’t yet had a chance to run these tests on a Cortex-A53/Cortex-A57 setup or a Cortex-A53/Cortex-A72 setup. The Qualcomm Snapdragon 615 has a quad-core 1.7GHz ARM Cortex A53 cluster and a quad-core 1.0GHz A53 cluster.

Thirdly, the scan interval for these statistics is around one third of a second (i.e. around 330 milliseconds). If a core reports its usage is 25% in that 300 milliseconds and another core reports its usage is 25% then the graphs will show both cores running simultaneously at 25%. However it is possible that the first core ran at 25% utilization for 150 milliseconds and then the second core ran at 25% utilization for 150 milliseconds. This means that the cores were used consecutively and not simultaneously. At the moment my test setup doesn’t allow me any greater resolution.

But having said all that. Clearly Android apps are able to take advantage of multi-core processors and big.LITTLE allows the scheduler to pick the best core combination for the current workload. If you still hear people saying things like “but a smartphone doesn’t need 8 cores” then just throw your hands-up in despair, as it means they don’t understand Heterogeneous Multi-Processing and they don’t understand that big.LITTLE is about power efficiency and not overall performance.