Are You Ready for Android L?
About the Webcast
Make sure you are prepared for the changes in Android L. This webcast is perfect for developers, testers and QA professionals who need to ensure the highest levels of continuous app quality and performance through the release of Google’s latest mobile OS.
Android L brings a brand new UI as well as new features to support and will require a renewed focus on ensuring that apps work together and ‘play nice’ within the new environment and with older versions of Android.
Keynote mobile testing and performance experts will walk through the latest beta version of Android L to help developers and QA teams understand how to ensure optimal performance with the new release, and how to:
- Test your existing apps and services in the new material design, the new Google-wide standard
- Support new features including the all new enhanced notification center, giving you control of where notifications appear
- Test and interact with the new ‘Recents’ feature
- See the value and importance of testing and monitoring on Android L on Day 1
Welcome to Keynote’s webcast, “Are You Ready for Android L?” My name is Josh Galde, and I am the Senior Product Marketing Manager here for Quality at Keynote. Today’s live demonstration will be led by Darren Madonick, a Customer Relationship Manager, and mobile testing expert here at Keynote.
Today’s webcast will help you understand the following: First, we want you to understand the ability of how you can test your existing apps and services in the new Google-wide standard “material design.” We also want to share with you how you can support new features including the all-new enhanced notification center, giving you control of where your notifications appear.
Third, we want to make sure you understand how to test and interact with the new “Recents” feature, and lastly we want to share with you, and show you how to see a value, and importance of testing, and monitoring on Android L on Day One.
Before we get to the live demo we would like to cover four rules to successfully prepare for Android L. First, it’s important to know what’s coming. We’ll talk a little bit about that, and talk a little bit about what’s going to be included in Android L, and how it can impact you as a developer or tester.
Second, we want to share with you the value of knowing your user’s experience, and when it comes to quality, and five-star ratings, and the importance of ensuring the quality of your application when testing in both pre-production, and post.
Third, we want to talk a little bit about the fact that obviously this will happen again, and the fact that this will not be obviously the last iteration of Android, and there will be many more to come so it’s important to perform ongoing testing, and to make sure that your app works, and functions as you intended in post-production.
And fourth, we want to share with you, and show you the importance of testing both pre-release, and post-production. We will then follow this with a live demo, and Q&A.
So the first rule is to know what’s coming. Nobody knows what sweet concoction will be the moniker for Google’s newest mobile operating system, but one thing everyone does know is this: Android L will be the biggest shake-up of the OS in years, both with functionality and aesthetically.
This ultimately will be exciting news for consumers, but for developers it means still another layer of permutations on top of the already crazily fragmented Android ecosystem, making it more important than ever to thoroughly test apps for compatibility with the new Android L as well as your users’ other main device OS configurations.
Recently, Apple released their newest version of iOS, and along with it launched extensibility, finally opening up iOS apps to allow for sharing of functionality, data, and access notifications to bring it on par with Android. Where Android has been strong in openness it has also struggled with its UI consistency across device form factors. So let’s take a look at some of the major impacts.
First, we have the most obvious change, and that is in the design. With Android L’s superlative new UI it seems that Android is now set to answer the call for a change, making it simpler, legible, and prioritizing the needs of app users.
Dubbed the “material design,” and described by Google as a “Visual language for our users that synthesizes the classic principles of good design with the innovation, and possibility of technology, and science are far more sweeping. More akin to the design overall from Apple’s iOS 6 to iOS 7 when Jony Ive’s flat design was introduced, but only more so.”
The card metaphor from Google Now has been expanded throughout the OS, and almost everything about the UI has changed visually with new colors, shadows, and animation throughout. Touches to the screen can trigger movement, and ripple effects giving users a heightened sense of control over the interface.
Also, there are animation effects, and even 3D tiles that can slide over one another. Not to mess up the ripple effect on task, and items in list makes it smoother, and you just can’t resist your love for the design.
At its core, the intention behind these changes remains quite simple. To bring in an element of consistency across all the user’s Android-powered devices including smartphones, Android TV, and tablets. Google’s new material design UI isn’t due to be released until October or November, but it’s already winning awards. It was recently awarded the Gold prize in the 2014 UX Awards.
Of course, what’s on the screen is just a reflection of the tremendous goings-on underneath the hood where developers will find more than 5,000 new APIs including new notification hooks, lock screen merger, and new hooks for Android wearables.
Android will run exclusively on ART, Android Runtime which was experimental in the KitKat release, but is now taking over prime time. The new OS will also debut on Android TV, and Android audio.
And Google is making Android more secure for enterprises by providing data separation and security through a new program announced at Google I/O called Android for Work. With the “bring your own device” movement today many work phones contain personal content, and personal phones are used for work purposes.
With Android for Work, Google is adding a layer of security to make phones more secure for sensitive environments. With the Android L release, Google is introducing new APIs to unify work and personal so that corporate apps can live on personal devices, and content can remain secure. Businesses can now deploy apps to users in bulk.
This will be natively supported in Android L, but Google promises that it will introduce an update later so that any device running Android Ice Cream Sandwich or later can benefit.
With Android for Work Google is rolling in parts of Samsung’s Knox security suite for the enterprise so there’s one protocol across all of Android. Device manufacturers like Sony, LG, Motorola, and HTC, to name a few, will all bring Android for Work to their phones.
Google says that Samsung has contributed some of its work with Knox to Android for Work. What that means is that developers won’t have to modify existing apps to make them enterprise-ready.
They will also provide a secure container so business-sensitive data doesn’t leak into personal usage of the mobile device. Before we move on, we want to show you a quick video of what the new material design will look like. Let’s take a look. (Video Plays)
Excellent. We hope that gave you a little insight into what this new UI is going to look like.
Android 4.4 or KitKat was released in October of 2013, and first made its public appearance on the Nexus 5. It now powers a whole range of smartphones and tablets, and has achieved a 24 percent adoption rate according to Google.
However, the reign of KitKat is slowly coming to an end now that Google has unveiled its successor, the Android L. This latest version or KitKat has a long way to go to catch up with the previous release code-named Jelly Bean.
The Jelly Bean, which includes versions 4.1, 4.2, and 4.3, still powers over half of the Android devices, and makes it the single most popular version in the market today. Android version 4.1 is the single most popular release powering almost a quarter of all Android devices.
All of this means that there is a considerable fragmentation among devices, even those running one version such as Jelly Bean, with the majority unable to benefit from features introduced in previous versions. With KitKat and Jelly Bean now powering over three-quarters of the Android devices accessing Google Play Store, the older platforms are slowly being squeezed out.
However, they are still likely to remain significant well into 2015, and beyond. By which time KitKat will have been superseded by Android L, and a new Android release will be fighting to gain traction.
That level of fragmentation makes it harder for developers to create new apps, and harder for users to get the best from their devices. Compared to iOS, where Apple has kept much greater control over operating system updates and makes sure that the vast majority of customers run the latest operating system weeks after it comes out.
And it’s not just the device in OS fragmentation, but you need to Android each manufacturer, and carrier for that matter, can customize each device even though it’s on the same OS. This is critical, and not found in iOS.
It is one of the main reasons for the low adoption rate that each really is compared with iOS adoption rate in the 80-90 percentile. What you see here is a list of devices that are planned to get Android L, and those that are not.
This is important as consumers waiting to get the latest version of Android on their device might not have the opportunity. Also, this makes it challenging for developers who will have to decide how far back they’re going to support Android. Again, adding to the fear of complexity, and fragmentation.
The second rule I’m going to cover is to know your user’s experiences. It’s important to understand, and maybe be reminded of the value of the user experience, and what can happen if the quality of the experience is not taken into consideration when updating an Android app or creating a new app.
Ensuring that quality can mean a difference between a five-star, and this. While there can be uncontrollable circumstances such as network speed, and relying on third-party applications, many times it can be simply the user experience as seen here.
Also, apps crashing has unfortunately become more common. This can mean life or death to many applications. In fact, just yesterday I updated my iPhone along with everyone else, and several of my iOS 8 app versions kept crashing. And one app had a feature that wouldn’t work because of the upgrade.
Even after you’re making these changes, you’re making these updates, you can run into problems. And not just seeing the change, but also having to fix the change in getting that deployed.
While the user is deleting your app, for example, you still need to take time to understand, and acknowledge the issue, transfer the information to engineering, validate the problem, build and test the fix, and deploy a new version of the app.
This is all extremely important and extremely time-consuming, so it’s important to get it right the first time. According to Econsultancy, only 16 percent of consumers will try a failing app more than twice before dumping it.
A poor mobile app experience is likely to discourage users from using an app again. There is a very narrow window to get it right, and thus no room for error. All of this underscores the need to test to ensure the best possible outcome for your users, and your business.
The third rule I want to share with you is to know that this will happen again, and I’m not just talking about Android XYZ, or whatever they come up with. See, it would be nice if we could build, and test, and ramp up for one release, and be done with it. Very much like desktop applications. But we all know that this is not the case.
The reality is that once you have launched a stable, updated Android app, there is an even newer version 5.1 followed by 5.2, et cetera, and actually a 6.0. And it’s not just Android, but updating your app to support other devices, and operating systems such as Windows Phone and iOS 8, is crucial. And it’s not just the OS versions, either, but the form factors as well.
Launching alongside Android L will be the new devices. Both Nexus 6 and 8 will be launching with Android L. New form factors come out all the time, especially when it comes to Android. You have new devices coming out all month, and all year. I think Samsung’s released over 30 devices in the last three years.
So with so many releases, and form factors to keep up with it’s no wonder many developers, QA organizations, and IT organizations are struggling to maintain balance.
We’d now like to take the opportunity, and get your feedback so we have a quick poll for you. The question is, “What is your biggest concern when it comes to Android L? Is it updating, recoding your current app to support new Android L functionality, and UI?” Obviously, this would be an important one, especially with this new version. Makes sense.
Is it proper test coverage for my application? So with complexity in the application you’ve got to make sure you’ll be able to reach as many devices as possible. Is it troubleshooting issues in production? Important making sure the issues are addressed both post-production, and well as in production, or is it low or no visibility as to how users experience your app?
One thing to note is if you do not see the poll questions feel free to minimize your screen. If you’re currently viewing it in full screen you’ll be able to minimize that, and be able to see the poll question, and be able to respond with everyone else.
So it looks like we’re getting some great responses. We’ll go ahead, give it a couple more seconds before we close the poll. Now is the time to get your last vote in. Okay, great. Let’s go ahead, and end the poll, and we will broadcast the results.
Great, it looks like updating, and recoding your app, current apps to support Android L functionality it looks like the winner with 42.8 percent. Proper test coverage won second with 39 percent followed by troubleshooting, and low or no visibility.
This is consistent I think with what we would expect with Android L, especially when there’s a major UI change like this, and so these results are not surprising, but they are interesting to see, and see what power the community on today’s colleagues responding, and where their concerns lie.
So the fourth rule is to test pre-release, and post-production. I’ve talked a little bit about this, but I want to give an opportunity for one of our testing experts here at Keynote to share a little bit about best practice that he has had working with his customers. So here are some best practices that we’re able to give you for you to apply when preparing for Android L, and beyond. I’ll let Darren take it from here.
Thanks, Josh. Yeah, I think that poll question or at least the responses that we got really hits home for a lot of people. And so these next couple of slides that I want to share with you guys will really help in answering some of those concerns or at least help you yield some capabilities to focus more on those specific concerns that you have.
So first, and foremost if you haven’t already, as a QA organization, obviously I’m sure your development teams have been picking away at the new Android SDK, but if you as a QA organization haven’t had a few of your QA members get familiar with the SDK Emulator that’s first, and foremost. You want to get some testing done on that SDK Emulator.
The SDK is the easiest way to familiarize yourself with the new UI, and it’s a great start to understanding the major changes that are coming in the next version of Android. And the best thing about it is it’s completely free. You can just download it directly off of Google’s site.
And then if possible get your hands on a Nexus 5 or a Nexus 7 2013, and load the developer preview ROM on your device. And this will give you more visibility with the way that the UI will behave with a real device in your hands.
We also make, for our customers that are currently using DeviceAnywhere, we make the Android L operating system, the beta version available to any of our customers who have private devices with Nexus 5s and Nexus 7 2013s.
And that’s the demonstration that I’ll show today. After these couple of slides we’ll jump into DeviceAnywhere studio, and poke around on a Nexus 5 that has Android L loaded on it, and we’ll play around with that. And we’ll show you some of the new changes on a real device.
The next thing that you’ll want to do is review Google’s Material Design to ensure that your app as it is today will present itself to your users as expected. And then you can decide which changes to your app you’d like to implement, and then adhere to those new design standards.
And of course, although most of the design changes do seem cosmetic, and everybody’s talking about material design, it’s important to recognize that there are more than 5,000 new APIs in Android L. The most important changes are changes to how the notifications behave as well as major changes to the ActivityManager API. We’ll go over some of the notification changes, and the changes in the settings so you can take a look at how that’s changed in Android L.
So once you’ve played around with the beta, it’s also important to note that right now it’s not clear how manufacturers are going to take advantage of Google’s new material design in Android L. In previous major upgrades, we’ve seen huge differences between carriers on the same device, same manufacturer at different carriers.
And then of course, different manufacturers are going to choose different customizations for their Android L devices. Also, understanding the upgrade process for your app compared with a fresh download from the Play Store can really help with diagnosing issues found in the wild, especially after a major release.
Finally, keep a close eye on the upgrade schedule for each of your manufacturers. Especially for the devices that hold the majority share in your customer base. So if you’re using Google Analytics data or some other data analytics software to focus or to understand your customer base. Focusing your testing based on these OS updates, and releases, and the release schedule can help you stay ahead of the upgrade game or at least be right there, and start your testing Day One.
So at Samsung, if you’ve got 20 percent or 30 percent of your app downloads coming from a Samsung Galaxy S3 or a Samsung Galaxy S4, I think that the Samsung Galaxy S3 is kind of out of the loop. I doubt Samsung’s going to update L for that, but at least the Samsung Galaxy S4, and I know for sure the Samsung Galaxy S5.
Keep a close eye on those update schedules, and see when they’re going to roll out, and then make sure that you’ve got a device available either through DeviceAnywhere or in your hand that you’ll be able to upgrade that device Day One, and focus your testing as soon as possible.
So now we’d like to take a minute, and go into a live demonstration. What I’ll do is bring up DeviceAnywhere, and I’ve got a Nexus 5 that we’ve loaded the developer preview of Android L, and this is the actual stock factory image. Let me just share my screen here. So this is the stock factory image that comes directly from the developer page for Android L. I’ve pushed the firmware to the device. I’ll share my screen here.
So we’ve got a Nexus 5 running Android L. The first thing that you notice or at least I notice from Android L is the change to the size of the icons. If you are already in a place where your icon on the device for your app is of lower resolution, this is going to make that even more apparent.
You’ll be able to see more granularity or more imperfections in your icon. It will look a little fuzzy. So that’s the first thing that you definitely want to pay attention to is that you’re adhering to the design standards for the new, larger icon size.
The other thing that’s happened is there’s a much flatter look. At least in the home screen, and on some of the apps that have been updated for Android L, there’s no longer a black notification bar. It’s kind of been greyed out.
And this is something that was introduced in KitKat, but now it’s something that has become even more apparent in Android L. Especially with the redesign, the change to the bottom buttons, and navigational buttons.
Now, your notification center is still here. The notification center has made a huge change in how flat all the icons look. When you get a new notification it will still show up here. You now have the ability to have overlay notifications within apps to give you the ability to peek.
One thing that you’ll notice here is that they’ve completely removed “settings” as a button click from the notification bar. You actually have to click on the top of the notification bar now in order to get access to some of the basic settings.
There are more options for these basic settings, however. One of the cool changes that Android L had made is the ability to either enable or disable from just a click toggle instead of a long press. Or the ability to press below in the name of the SSID, or the name of the application, or I guess notification, or setting, and actually jump directly to that setting inside of your main pull-down window there. So it makes it a lot easier to get at what you need directly from the notification bar of Android L.
So let’s take a look a little bit further down in the settings. Now, once you’ve clicked on the settings pull-down at the top you’ll have the ability to click to get directly into settings. This is the same as if you launched the settings application from the app drawer, of course.
The major difference here is the flattened style, and so one of the things that you’ll want to take a look at is how your app currently looks, and does it take advantage of this flattened look? I guess Holo on steroids. They’ve kind of made a change here to make things even more flattened with material design. It does follow the traditional Holo look, but it definitely has a cleaner feel to it, and a more simplified feel.
The one thing that I wanted to really focus on is this new change to notifications. Previously on KitKat, and previous you would have sounds. Now, you’ve got sounds, and notifications. So if you click on this section, and you scroll all the way down to the bottom, the user now has the capability to see what notifications they want to receive from which applications.
So they have the ability now to really at a very granular level decide whether they want to see or not see notifications. And so obviously these settings here, when the device is locked or when Do Not Disturb is on, these are some sounds. Also, some of these settings are from the privacy section. They’ve now been consolidated into this notification section, but what I wanted to really show is this app notifications.
This is giving you an entire list of all your applications that are installed on the device. And then you can click on a particular application such as the Chrome browser or the clock, and actually choose whether or not you want to show notifications from that particular app. So this is a very important change, especially if you’ve got users that start selecting to hide notifications for a particular app.
And then perhaps you’ve changed how your notifications work in a new version of your app, and you want to be able to force them to show notifications again on a reinstall or an upgrade. Those are APIs that have now changed, and you’ll want to make sure that you take advantage of those as well.
The look, and feel of Android, it’s pretty much maintained the same. The apps that have run or I should say the home screen has pretty much stayed the same, especially from any other stock version of Android. The carrier customizations aside, this stock version of Android does look fairly similar.
And then the app that have not been updated will still have that old look, and feel to them so Google Play still has its sidebar drag-out, and has not yet been updated for L, but it will be I’m sure shortly once the actual release is imminent.
But these are the kind of differences that you can see that you want to definitely take advantage of, the time that you have now before Android L is coming out, and familiarize yourself with how your app behaves currently, and then how these new apps for Android L with a material design will take advantage of some of these new APIs, and some of this new look.
Excellent. Thanks, Darren. That was great. We’d like to take a few questions from you so if you could go ahead and submit. Feel free to submit your questions in the Q&A panel at the bottom, and if you can’t see the Q&A panel, a reminder just to, you might still be in full screen mode so just unclick that box, and you will be able to see the panel.
We’ll go ahead and give a second. Let people submit some questions. We’ve already got a few from earlier from your pre-submitted questions so we can start with those, and let people ask some unique questions.
So we’ve got a couple of questions here for you, Darren, particularly around Android L, but more so around real devices, and why it’s so important to test the real devices versus emulators, and when would you do that in the process, et cetera? What do you recommend to your customers when it comes to that?
Well, right now you’re very limited on real devices. Android L, a working build has only been released. At least an official working build. We have a couple of developers that I know in the scene. XDA Developers in a couple of other places like that are building their own custom ROMs for Android L already.
But the official ones from Google are only supported on the Nexus 5, and then the new Nexus 7. The 2013 model. So if you want to test on real devices obviously there’s some value there, but not a whole lot. The real value on testing on real devices comes when the manufacturers start declaring their upgrade schedule so Android L itself will be released for Nexus devices, and then stock devices at a TBD date. I think it has been officially set in stone yet.
But the manufacturers are going to lag weeks behind that. Sometimes months, and we’ve seen in certain cases a manufacturer that says that they’re going to come out with a version of Android for a particular device, and then they retract that. So it’s important to stay up on each of the manufacturer’s plans, and then understand what their upgrade schedule is going to be like that because there is no one date for Android L.
Unlike iOS that’s closely held between the manufacturer, and the designer of the operating system, Apple gets the luxury of being able to choose when an operating system is released. When Android L’s released the fragmentation is quite large because each manufacturer, and then each device is going to have its own release date for when the Android L upgrade is going to happen.
Excellent. And speaking of the emulator, have you seen any changes when it comes to the emulator? Will they be the same, or what have you seen thus far in working with it?
Yeah, so the beauty of every Android release is more likely than not every single app tends to work at some level. It will at least launch. Where you’re going to start seeing your issues or at least eyesores in particular are going to be in your notifications areas. And then how your app icons, and your notifications look today compared to when they are overlaying on top of other apps inside of Android L when material design is released.
So once those capabilities come out, and you have the ability to play around with that, you definitely want to focus your testing on some of those kind of eyesore, nitpicky areas. The major one is going to be the way that material design looks in general. You’re going to want to focus, and check out how your app looks, and behaves today, and compare that with the reference design of material design in order to check to see if your customers are going to start having an adverse experience to your app because they’re expecting your app to behave in a certain way that it’s not behaving today.
Like the slide-out, pull-out notification drawer on the top left being able to have a smooth, unique UI between horizontal, and vertical portrait, and landscape modes. And then the carry-through of the ripple effect through your various different sections of our application, especially when it comes to hybrid applications where you’ve got sections of your app that you might currently be relying on a web view.
Those material design capabilities aren’t going to pass through in those web views, and so you might get an adverse experience. And you might want to think about possibly pulling some more of your elements from web view into a native experience so you can carry that material design through a lot cleaner throughout your app.
Okay. Are there any stability issues addressed on Android’s Emulator particularly ADB connection keep breaking, et cetera?
Well, I think that that’s something you’ll need to take up with Google. I definitely have seen some flakiness with the SDK, and the emulator through ADB connectivity, but for the most part if you’ve got your drivers configured correctly, and you are running enough RAM in your box, it should definitely maintain connectivity. Although you are not alone. Whoever asked that question, you’re certainly not alone in some of those issues that present themselves in the SDK Emulator.
Got another question here. What are the changes in DDMS to enable debugging, and testing if you know that?
Yeah, unfortunately I’m not as familiar with DDMS for debugging probably as I should be. I’m definitely not an Android developer by any means although I have done a few simple applications. The best thing to do is be able to instrument your application wherever you can with a third-party analytics capability to get some feedback immediately, especially with your applications that are already in the wild.
Great. Okay, got another question here. And I know we’ve had – I’ve seen some stuff online about, “What is it gonna stand for? Is it gonna be Lollipop? Is it gonna be Licorice? Is it gonna be some candy name? Do we have any insight to that?
I think there might be a pool going, and then Android might or Google might just be holding out for Willy Wonka to come in, and try and throw them some cash to get some naming rights there. My money’s on Lollipop, but I was definitely wrong about KitKat so who knows? I guess if I knew I’d be a much richer man.
Yeah, and that’s a great segue into, as far as L goes, and as I understand they’re looking for a company that’s gonna own it and sponsor that so as what they did with KitKat.
Before we move on to our next question we just want to remind everyone feel free to submit questions. We’re still getting a lot of great questions so I just want to take a reminder. We have a few more minutes to answer questions today because we were able to complete most of the webcast pretty early. We do have a couple more slides to cover, but we will get to those shortly. So next question here is from Nav. “Would material design and ripple animation be available for API 8?”
Yeah, we’re starting to get into a few questions that I actually don’t personally know the answer to. We can certainly try and get some more feedback, but as far as certain API levels, whether or not they’re going to have the visual differences for material design I unfortunately am not able to answer that question.
Okay. They can also Google it. That’s a good idea.
And then, I don’t know if you know this, but do you know if the UIAutomator works with Android L? Have you heard anything about that?
What I’ve seen from the actual ROM is that things like ADB shell, getEvents, certain things are currently blocked, and I think this is on purpose. This is something that Google is doing on purpose. I have not actually played around yet with UiAutomator for Android to see if UiAutomator is blocked on real devices, but I do know that quite a few commands have been blocked by Google. So I wouldn’t be surprised if UiAutomator is not yet working for Android L in the current state that it is.
Okay, and the last question here is around availability, and I know we’ve been answering this as much as we can, but just as an understanding when it comes to each mobile, so each mobile flash tablet may, in fact, will have separate dates for Android L, and will it be Nexus devices? Android L would be first or is that what you’re hearing or what do you recommend?
So what we know for sure is that the stock images will be released on the Android stock image page for sure for the Nexus 5 as well as the 2013 Nexus 7. There’s been speculation that the original Nexus 7 will get it, possibly close to Day One, but there hasn’t been any guarantee of anything besides the Nexus 5, and then the Nexus 7 2013.
Now, different manufacturers are going to have different release dates so there’s going to be a stagger between, let’s say the Samsung Galaxy Note 4, and the Samsung Galaxy Note 3. The UI may end up being similar or different. Most likely Samsung will standardize on a particular design scheme for most of their Samsung devices that do receive L the same way they kind of standardized on the Samsung customizations today across their devices.
But as they start phasing out certain models or they come to the final determination of which devices are gonna get the upgrade, and which devices are not going to get the upgrade that will become a lot more clear as far as street availability date.
Not only that, but the manufacturer needs to then go through a soak test, and a final sign-off by each carrier. So not only will you see staggering differences between manufacturer release dates, but you will see a staggered difference between when they Verizon Samsung Note gets its upgrade, and when the AT&T Galaxy Note gets its upgrade so there will be differences there as well.
Okay, great, and this is a great segue because the last question was, “How is Keynote getting ready, and what are we doing?” So Keynote has already begun. We’ve already begun planning for which devices we’re gonna support on Day One, and in this case it sounds like we’re gonna have multiple Day Ones.
Our plan is to support for Android L, as I mentioned earlier. This is slated for October/November timeframe, and if you’re a customer of Keynote you’ll be the first to be notified. That includes the Galaxy S4, S5, the Galaxy Note 3, the Nexus 5, the HTC One M8, and the LG G3. These devices will be ready, and waiting to test, and monitor in the new Android L environment as soon as they are updated.
We also have planned support for new devices that we launch with Android L including the Nexus 6, and the Nexus 8. As they are deployed in the marketplace we will be quick to deploy them in our device cloud as well for easy functional, and automated testing.
Let me just also talk a little bit about your customer. So if you’re an existing customer, and already working on beta Android L versions on their devices you can update your devices today. If you have a device already, you’re already a customer please talk to us. We’d be happy to do that for you.
Secondly, our engineering team is busy working on upgrading our Android L support for our object-level scripting which is the robust test automation platform that we offer. We just want to make sure that we support Android L on Day One, and so we’ve already begun to ensure that that will happen.
So as far as functional testing let me just talk a little bit about that, and how Keynote, how we support functional testing whether you’re a customer of Keynote’s or you’re new to Keynote. Cover a little bit about that.
As applied to functional testing, and mobile app, and websites, there’s obviously no substitute for real devices. Our real carrier networks using real mobile browsers. Our platform gives you an efficient and easy way to test any mobile application including native, hybrid, or web from anywhere in the world.
How do we do this? We’ve built the world’s largest cloud library of real mobile devices including Android, iOS, Windows, and others built on Keynote’s patented Direct-To-Device technology.
With this technology we are able to integrate any mobile device via software or hardware electrical connection. Any action that can be performed on a mobile device in-hand can be done with our testing platform. This technology is the reason we’re able to give our customers the best and most accurate cloud-based mobile testing solution on the market.
And for post-production monitoring we also offer a mobile app monitoring solution. Mobile app monitoring continuously interacts with your apps 24/7 exactly like a customer does in the real world. It is the only 100 percent cloud-based solution requiring no modifications to the app being monitored. It’s perfect for your operations teams to be able to monitor and report back to you the data you need to provide the best user experience.
Great, so we just want to wrap up with some steps to kind of avoid this fragmentation madness, and what you can do, and what we would recommend. First, automate your test cases. If you’re in QA, being able to perform aggression testing of a functional test case, it’s critical to being able to be more efficient resulting in more testing, and thus a better app.
In our 2014 Mobile Quality Survey, we found that only 14 percent of respondents were automating more than 50 percent of their test cases. That tells me there’s a lot of manual testing going on, and more automated testing is needed.
Second, as Darren mentioned it’s important to test on real devices available 24/7. Sure, emulators have their place, but nothing beats finding a bug on a real device pre-release that can minimize costly app fixes later. And having devices available 24/7 can enable remote or distributed teams to run testing on the same devices around the clock if necessary.
Third, it’s important to use best practices for continuous integration. Developers, testers, and managers are moving away from traditional testing late in the development to early, agile testing practices, especially in mobile.
Many teams are adopting continuous integration tools such as Jenkins to speed up, and streamline their development, and testing processes in order to meet the demands of this condensed mobile center timeframe. Testing on real mobile devices through this integration tool gives you the most accurate view into how your mobile app or website will perform in the real world, all in a pre-production environment.
And fourth, it’s important to use a central repository of the number of test cases you have to deal with for both manual and automated, that you want or need to run against your application. This one is pretty simple. There are tools that can help by centralizing all these test cases.
Depending on how many of the APIs and app extensions utilized both in iOS 8 and APIs in Android L, we estimate that we could see up to a 10x increase in test case creation on one app alone. So dump the spreadsheets and centralize what you have. Build it right, and make it easier on yourself and your teams, especially if they are distributed in other regions.
And lastly, it’s important to continuously monitor the quality of services of your app post-production. For QA, data and analytics can provide valuable information to help refine, improve, guide you to maintaining success, and stay above the fray.
Recently, it was estimated by comScore that roughly 65 percent of those surveyed downloaded only one new app per month for their smartphone. This was from January to June of this year. Even as their total app usage time increased, consumers are getting comfortable with their apps that they have on their devices, and this tells me that improving my app quality is critical in retaining customers.
Excellent. Thank you all for your time, and why don’t we go ahead and take you to what a lot of you were asking in terms of how you can get started. Follow up with questions. So as I mentioned, if you’re a current customer we can upgrade your devices with Android L beta right now.
If you are not yet a customer we invite you to take a trial of our mobile testing platform to test your current KitKat version, and also pre-test your beta version. Your app on your beta version of Android L, and for those that don’t have time to test feel free to contact one of our Android L-enabled partners below.
For more on Android L click on “learn more.” You can also click on a few other links. There’s one on Mobile Testing Pro. You can get a free trial, as I mentioned, and you can learn a little bit more about mobile app monitoring.
And for those that are interested in today’s presentation feel free to download the PDF of the entire presentation so you can share with your teams. Thank you so much.
Duration: 50 minutes