Android Wear: What’s New & Best Practices (Google I/O ’17)

Android Wear: What’s New & Best Practices (Google I/O ’17)

[MUSIC PLAYING] DAVID SINGLETON: Good morning. Hi, folks, and welcome to
What’s New in Android Wear. My name is David Singleton and
I lead the Wear team globally. It’s been a really
busy year for us. And I’m really excited to be
able to share some updates on Android Wear 2.0, and
also some of the new watches that are coming later
this year with you today. So even before the
Android Wear 2.0 launch, we were seeing really nice
momentum in this market. During the holiday
period last year, we saw 72% growth in
new devices activated compared to the year before. And since the launch
of Android Wear, we’ve always said
that people should be able to wear what they want. And part of this is
the choice that users have between a host of different
designs and styles of watch. And we can only deliver
that through partnerships with iconic brands. The number of brands
supporting Android Wear doubled from 12 last
year to 24 this year. And the choice of
Android Wear watches has doubled from 23 last
year to 46 this year. And we’ve seen continued support
from our consumer electronics partners. And now they’re joined by
their fashion counterparts. And this means that
whatever your style, our partners have
a watch for you. For example, Tag Heuer
have updated their lineup with the Connected Modular 45. It’s a really innovative
hardware design, which means that you can change
everything from the horns to the bracelet and the clasp. Another partner
that’s refreshing their lineup this
year is Michael Kors with their new Access
Grayson and for men and Access Sofie for women. I love these watches. They’ve done a really
nice job with the design, and with watch
faces, including one that lets you put Instagram
photos right there to see throughout the day. As well as existing
partners, we’re also welcoming a bunch of
new partners this year. And we’re excited
to see partners like Movado, one of the
most iconic watch brands, bringing their
trademark minimalist designs to Android Wear. Aside from watch hardware,
we’re seeing app developers, like many of you in the
room and on the live steam, take full advantage
of Android Wear 2.0. We know that people
love to stay connected while they’re out and about
via their Android Wear watches. And our partner
Telegram is taking full advantage of the standalone
functionality in Wear 2.0. Not only does the
app work the same way if you’re connected to an
Android phone or an iPhone, but when you’re watch has
a cellular connection, it even works without the phone. And so sending
stickers, like you can see in this little
video, to your friends has never been easier. Another great experience made
possible by the rich display on Android Wear watches
is getting coaching while you’re working out. So let’s take a look at
this app from our partner 7 Minute Workout. This app’s really great. I really love using it. It guides you through 12
30-second long exercises. And you don’t need
any fancy equipment. Just a wall, a chair,
and your Android Wear watch, and you can use it
to stay fit and healthy. Another feature that
we added to Wear 2.0 is the ability to have
complication support. So users can now
select the watch face that they love the look of and
have the important information that they care about available
at a glance throughout the day. Here you can see Robinhood,
the financial investments app, is showing your overall
portfolio’s value right there on the watch face. And tapping on
that, if it’s maybe changed in an interesting way,
takes you to their watch list. You can then tap on
individual stocks to see their current value
and the trend over time. So we see that the best
Android Wear apps really focus on users’ needs
and what they care about, and then play to the strengths
of the wearable form factor, as you can see here. As part of the Wear
2.0 launch, we also announced that the
Google Assistant is now available right on your wrist. You can find answers
and get things done by starting a
conversation with Google. And we have some
new features here. So for instance, you
can now long-press on the crown on your watch and
say, send a WhatsApp message to Felicity, who’s my wife. And the assistant will deal
with the interface presentation, message dictation, and deliver
to WhatsApp just the data that it needs to
complete that action. So we’re testing this
functionality right now with selected partner
apps, and it’s going to be open to all
actions on Google Developers in the coming months. In the meantime, if you
can’t wait to get started, you can develop your actions for
the Google Home and the phone today, and your actions
will automatically be adopted for Wear
when Actions on Google is enabled for Android
Wear coming soon. No additional work is
going to be required. And that means that
going forward, as well as notifications, watch
faces, and native apps, you have another option to bring
your service to Android Wear. And we’re super excited
about the new capabilities that this is going to bring. So in the rest of this talk, Jen
from our user experience design team will give you an
update on material design and what we’re doing to make
designing and developing an Android Wear easier. After that, Griff will highlight
some of the Android O features that are of particular interest
to Android Wear developers. And finally, Nancy will
talk about power and what you can do to conserve battery. So with that, I’d love
to hand it over to Jen. [APPLAUSE] JEN FERNQUIST: All
right, hi, everyone. I’m Jen and I lead User
Research for Android Wear. So today I’m going to talk to
you about some of the changes that we’ve made to Wear 2.0 as a
result of research and feedback that we’ve received
over the past year. So I’ll go over some
design guidelines, some common pitfalls,
and how we’re working on improving the
developer experience. To start off, I just
want to say thank you so much for all of the feedback
that you guys have given us over the past year on the
Android Wear Developer Preview. So we’ve made many
improvements to the platform as a direct result
of your feedback, like bringing back theater
mode and swipe to go back. So thank you. [APPLAUSE] OK, so today I’m going
to cover three topics– watch face complications,
Android Wear UI design, and developer feedback. All right, so first, let’s
talk about complications. So a quick refresh
of terminology. A complication is a piece of
information on the watch face that tells the user something
other than the time. So like these
highlighted bits here. So last year at Google
I/O, we introduced new EPIs to help developers
build complications. They enable any app
to supply information to be displayed
on the watch face. And they also allow
any watch face to be able to present that
information to the user in a way that fits its style. So we found in user
research that people really like complications. They like being able to
choose the data that they want to see at a glance
and which actions they want to perform quickly. So here’s a series of
watch faces from one of our user studies. Now, these are actual
screenshots of watch faces that participants had
set up after they’d been using their watches for a week. So we didn’t give them
any instructions on how to set up their watch faces. They customized these
all on their own. And I’ll point out a couple
of interesting examples. So in this watch
face on the bottom, the user wanted quick
access to their music. So they set a complication to
launch the Google Play Music app. And in this
complication on the top, the user wanted quick
access to their schedule. So they’ve got a
complication to show the name of their
next meeting, one to show the time of
their next meeting, and one to show their
unread notification count. So in user research, we
also learned something that frustrates
users, and that’s watch faces that look like
they have complications, but the data is
actually not editable. So users quickly
become used to being able to change the
data on the watch faces to be whatever they want. So if you’re a
watch face creator, then don’t just display a
static set of information on your watch face. Adopt the Android
Wear complication API to let your users choose
the data that they want to see. And if you’re an
app developer, then think about what information
that your app provides that users might want
to see at a glance. All right, so we learned
that complications are great and users love them. So why haven’t all watch face
creators implemented them? The answer that we hear from you
is that it’s hard, especially if you’re implementing
everything from scratch. So watch face developers
have the freedom to draw complications
however they want, but that means they have to
handle everything themselves, including the text size,
position, style, and layout. So to make it easier,
we’ve added two components to the Wearable
Support library– TextRenderer, which
auto-resizes text to fit the area
that you specify, and ComplicationDrawable,
which goes one step further and completely renders
the complications for you, if you tell us the location,
style, and size that you want. Yea. [APPLAUSE] And one other thing that
makes it really difficult to create complications is
implementing the configuration screen, like this one
that you see here, which can show the user exactly
where the complication is laid out on the watch face and
all of the different things that they can customize. So to help you
implement this part, we’ve created a
watch face setting example posted on GitHub
that you can take and easily adopt to change however
you want it to be. And after coding,
then comes testing, and so to help you
with that, we’ve created an open source
test suite data provider. So this makes it easy to
check that all types of data are going to look good
on your complication on your watch face. And since it’s open
source, you can also supply your own data if you
want to test for a specific use case. And if you want to find out
more about all of these tools, then go to the Android
Wear UI session tomorrow where one of our
lead engineers, Oli will talk about the
Complications API And walk you through a
bunch of these tools. There it is. All right, so the second
topic I want to talk to you about is Android
Wear app design. So last year, we introduced
a number of new UI patterns as part of the Android
Wear 2.0 Developer Preview. So we’ve learned a lot from
your feedback in the past year and we’ve updated the guidelines
on when to use certain features and when not to. So for example, take the
Wearable Navigation Drawer. So this should be used for
infrequent context changes, like accessing settings,
logging out, or switching users. If your app has a small number
of discrete functions, however, then instead of using
the navigation drawer, it might be better to use
multiple app launchers. So say you have a
fitness app that has two discrete functions– activity tracking and
historical analysis. So you can put these
functionalities under two different
launcher icons. And so another
question that we get asked a lot is, how many
launcher icons can you have? The answer is as
few as possible, but as a rule of thumb,
we’d say no more than three. And in addition to those updates
on the material design spec, we’re also launching
two things to help both designers and developers
build wearable apps. For designers, we’re providing a
sticker sheet on the spec site. Yeah– sticker sheet on
the spec site, sorry. Definitely utilize this,
because not only will it help you make your
app Wear native, but it’s also much easier
to try out different layouts and designs in something like
Sketch rather than in code. And for developers, we’re
starting the journey to open source the
Android Wear UI library. What this means is you
can expect three things– consistent and stable
APIs, frequent releases, and better responsiveness
to feedback. And if you want to
find out more, please go to Aga’s session
tomorrow on Android Wear UI. And yes, this is
the same session where Oli will be talking
about complications. And last but not least, I want
to mention developer feedback. So in the past year and a half,
we’ve periodically sent surveys to the Wear developer
community trying to identify the top pain points
to developing apps for Wear. And so as a result
of that feedback, we’ve made improvements
to the emulator, we’ve simplified the
API, like in the work we’ve done with complications
and the UI library, and we’ve adopted more examples
into the Developer Guide to help developers get up and
running on their projects. And so we want to continue
to make improvements to the developer experience. So if you have any suggestions
on what we can do better, then please file a feature
request and we will get on it. And thank you again for all
of your feedback thus far. And with that, I will
hand it over to Griff. [APPLAUSE] GRIFF HAZEN: Hi,
I’m Griff Hazen. I’m a software
engineer and tech lead on Wear’s Developer Platform. I’m here to showcase a few
of the new Android platform features of particular
interest to Wear developers. But first, I have a general
Wear developer announcement. Earlier this year, we launched
the Play Store for Wear as part of Wear 2.0. It allows you to search for
and install apps directly on the watch. We also automatically
suggest apps to install if the user
has them on their phone. They also have a Wear version. Developers upload
their watch app to the Play Developer
console, just like phone apps. The same app can include
watch, phone, or APKs from other form factors
at the same time using the multi-APK feature. When the user installs
an app on their device, Play Store will automatically
select the right APK to download. This works great on Wear
2.0, but if your app also supports Wear 1.0, it
can get complicated. The old way to do
this for Wear 1.0 required the developer to
embed their wearable app within their phone app. When the user installed
the phone app, the wearable app was
extracted and sent to the Wear 1.0 device. This setup caused a
number of complications, including increased phone APK
size and a coupled release process. I’m happy to announce that we’re
starting to roll out a new way to distribute– improved way
to distribute your app for Wear 1.0. The new flow, coming
soon, uses multi-APK. It allows you to distribute
your Wear app the same way for both Wear 1.0 and Wear 2.0. When a user installs
your phone app, if you have a compatible
Wear up in the Play Store, it will automatically be
installed on Wear 1.0. This feature is currently
being tested with a few apps. We’ll be opening it up to
all third party developers. You’ll soon be able to stop
embedding your Wear app with your phone app. If you’re developing
for Wear 2.0 already, you’ll want to make sure that
your app works well on Wear 1.0 if you set a low
minimum SDK level. All right, now back to my
main topic, which is Android O and Wear. The What’s New in Android
talk yesterday covered many of the updates to
the Android platform for Android O. Android
O also has a lot to offer Wear developers,
and I’ll showcase a few of particular interest– notifications, autosizing text
view, and background limits. First, notifications. Notifications posted
by phone and watch apps continue to be a
cornerstone feature of Wear. Android O has added
a few new APIs to make it easier for users
and developers to control them. The most prominent one
is notification channels. Notification
channels is a new API to organize notifications
of the same type so they can be controlled
by the user together. All notifications in a channel
share the same behavior when posted, like vibration,
interruption level, et cetera. On an Android O
phone, when the user long-presses a
notification, they can quickly toggle
future notifications from just that channel. They can also tap
to get to the phone notification settings
for that app, where they can control other channels
and notification behaviors. Starting with Android
O, all notifications need to be posted to a channel. Here’s an example
for setting one up. First, create a
notification channel object and provide a unique ID,
a user visible channel name, and an initial
importance level. Next, set some
optional properties, like vibration pattern
and description. And call Create Notification
Channel to create the channel. Once this is done, you can
start posting notifications with that channel ID. The Android Wear SDK
for O does not yet include a settings
UI for channels, but the APIs are
available now for testing, and we’ll be providing
updates in future previews. The next feature
I’d like to cover is an update to Android’s
TextView control to support the automatic
sizing of text. Android Wear devices
have small screens. And real estate and readability
are important considerations. With user provided
or localized text, it takes extra care to make
sure the content fits well on the screen and is readable. In Android O in the
support library, TextView has a new
feature that allows it to automatically
select its text size to fill the available space. The screens above show the
same TextView layout adapting based on the contained text. This API includes two ways
to control this behavior. The first is to provide a
minimum and maximum text size and TextView will select
a size within that range. The second is to provide
a list of preset sizes. Here’s an example using the
list of preset sizes in XML. To turn on autosizing, first
set the new autosize text type property to uniform. Then provide the
presets by setting the autosize preset
sizes property to an array of text sizes. Both methods can be configured
in XML or programmatically. And also, previewed
in Android Studio. The support library has
been updated to include compatibility on older
versions of Android, including all Wear versions, so you can
start using this in your apps today. My final topic is
background limits. As our next speaker,
Nancy, will detail shortly, preserving battery life is
one of the most important considerations when
developing a Wear app. We all want to create
responsive and useful apps, but also make sure
that the device can last through the day. Android O brings with it a
number of platform changes to help accomplish this. Android allows apps
to run and respond to events in the background,
but when too many apps are running or
execute for too long, it can overly consume limited
resources like RAM and battery. Background services
and apps targeting Android O have new
limitations on how long and when they can execute. In general, if an app no longer
has a foreground activity or service running, it will be
considered idle, at which point all of its services are stopped. In past versions
of Android, an app could also register for implicit
broadcasts in its Android manifest. This made it a bit too
easy for many processes to spin up for common events. This is no longer
supported in general, but your app can still register
for these events at runtime. A few best practices to
preserve app functionality. The JobScheduler and
AlarmManager APIs can still be used to
run background work at appropriate times. There’s also a new class in
the support library, the Java IntentService, which
uses JobScheduler on Android O and a fallback to
just regular services on older platforms. When your app receives a
Firebase Cloud message, it will also have
a window of time to execute before
being considered idle. If you really need to run,
you can start your service in the foreground. A notification will displayed
to the user while it is running. Receiving location
updates in background apps is another area where there is
a behavior change in Android O. It was found to be a major
contributor to power issues with background apps
being allowed to register for high rates of updates. In Android O,
background services are now limited to receiving a
few location updates per hour instead of having
unlimited access. As a best practice,
you can switch your app to use the batch location API. Your app will still
receive location updates at a reduced rate,
but each update can contain multiple
location events. If your app needs to
continue receiving a high rate of updates, for
example, it’s a fitness app and you’re doing a run, it
can start a foreground service and continue getting
the faster rate. This is a brief look
at a few Android O features relevant to Wear. There are more detailed
talks available, for example, the background
check talk by Ben Poiesz, and there’s a notification
talk this afternoon at 4:30 PM. If you’d like to try
some of these APIs on a watch form factor, the
Android O Developer Preview has been updated to include a
new version of the Android Wear emulator. Thank you. And with that, I’ll hand over
to Nancy to talk about power. [APPLAUSE] NANCY ZHENG: Thank you, Griff. So hi, everyone. My name is Nancy and I’m a
software engineer and tech lead of the Wear Power team. So over the last year,
the Android Wear team has been doubling down on
improving the battery life of the Android Wear platform. And we’ve developed a
set of best practices that we’d like to
share with you today that can help you improve the
battery life of your Wear app. To get started, I’d
like to give you a sense of how much battery we
have to work with on the watch. So here is a representation of
battery capacity on the Pixel XL and Pixel phones. Now compare that to two
of our recently launched watches, the LG Watch
Sport and Style. As you can see here,
our watch batteries are about 1/10 the
battery capacity of their phone counterparts. So that’s really
not a lot of battery we have to work with here. But despite this, Wear
users expect their watch to last all day long,
because oftentimes, having a dead
watch on your wrist can be worse than
having a dead phone in your pocket or your purse. But what are some of the things
that use battery on your watch? Well, one of the key
drivers is the display. Now, on Android Wear
watches, we have a lot of different types of displays. But for the next
couple of slides, I’m going to focus on an
OLED display as an example. Now, here we have the power
draw when the display is off. Compare that to an
always-on display. And again, compare that
to an interactive display. As you can see, with
each step, the power draw increases substantially. And that means that the
battery life will decrease. So the takeaway here is that
reducing interactive display time will save power. One way to do this is to
reduce the amount of time that the user has
to spend in your app by making it quick
and easy for the user to do what they need and
move on with their day. Sometimes you might need to
continuously show information to the user. And in those cases, you
should implement ambient mode. So in ambient mode, you
should switch your UI to a black and white color
theme and only update the display once a minute. And this will allow the
application processor to go to sleep in between
and conserve power. Another thing you should
consider is using dark themes. Now, in our
experiments, we noticed that an all white display can
use up to seven times more power than an all black
display in interactive mode. And so if you’re writing
a watch face or an app where you expect a lot
of user interaction time, you should switch to
using a dark theme. Now, aside from just
color, animations are also very expensive. Now, remember that display power
chart from a few slides ago? Here’s how it looks
with animation power usage in the mix. Now, before you panic,
remember that most animations only last fractions of a
second, and so aren’t usually cause for concern. It’s a different story,
however, if you’re working with a long-running
animation, such as a loading spinner. This is why, in Wear 2.0, we
switch our framework loading spinner from the one on the
left to the one on the right. The difference here is that
we’re only rendering one out of every three seconds
in our low power spinner. And just by doing this, we
saw a 3x power improvement. So if you use the default
framework spinner on Wear, you will also get these battery
savings, which you should do. Another example of animations
is with the watch face. Watch faces that have
a sweeping second hand, like the one on the left,
uses substantially more power than watch faces that use
a ticking second hand. So if a ticking second hand
works with your watch face stylistically, you should stick
with that one to save power. Aside from the display,
another major battery hog is network usage. So perhaps the
biggest battery issue that we have on
Wear devices today is unnecessary
background syncing. Now, let me give you an
example of an anti-pattern that could happen. An app could be periodically
sending data between the watch and the phone or the cloud. Periodically, let’s
say every 15 minutes. When the user is not
actively using your app, there should be no
reason for your app to be syncing periodically
in the background. The only exception
to this is if you need to alert the
user of something, like a message or notification. And in those cases, you should
use SCM push notifications. Having said that, if you really
can’t avoid background syncing, you should at least
try to batch your data. And we recommend batching
to transfer once per day, and preferably, when the
watch is on the charger. And you can do this using
the JobScheduler API. Now, I have talked a
lot about network usage, but you might be wondering,
how much of an impact is it on the battery really? Well, I’m glad you asked. Assuming you want to transfer
10,000 one-kilobyte chunks of data throughout a user’s day. If you do this in one batch,
in one 10-megabyte batch once per day, you’ll use about 1%
of the user’s battery, which is OK. But if you do not
batch this data and send this in 10,000
separate batches, you will end up using
over 100% of the battery on certain devices. So the difference
is night and day. So always batch your data. Now, another scenario
I want to discuss is if you have to transfer
a large chunk of data. An example might be if the user
wants to download some music or if they want to download
an app from the Play Store, for example. If you are transferring
more than a few megabytes, you should use a high
bandwidth network, such as Wi-Fi or cellular. Here’s an example of the
cost of transferring data over different radios. We have here Wi-Fi,
cellular, and Bluetooth. So with one-megabyte case,
the difference is not so huge. But let’s look at
what happens if we’re transferring 30 megabytes. As you can see, Bluetooth
is much more power intensive than
Wi-Fi or cellular. So to transfer data
over Wi-Fi or cellular, you can use the
NetworkRequest API shown here. Unlike on phones, starting
in Wear 2.0, using this API will actually turn
on these radios if they’re not already on. And of course, there is a
cost to turning on radios, so you should only do this
if you’re transferring a large chunk of data. In your network
request, you should include a network callback. And once a network that meets
your needs is available, you should get a
callback and bind to the network
that was provided. And then you can make
your data transfer there. And when you’re done, don’t
forget to release your network request. This will allow the
framework to turn off these radios to conserve power. So for more examples of how
to use the NetworkRequest API, you can visit our
Developer Guide by searching for
Android Wear Networking. Now, aside from the
display and the radio, there are also other
expensive features on the watch that
you might be using, such as vibration,
location, and music. I don’t have time to go
into all of these today, but just remember to use
these features sparingly because they’re very expensive. Also, if you want to debug
your app further and look at how your app is
doing on battery life, you might want to try
out Battery Historian. You might have seen
previous I/O talks about how to use Battery
Historian to debug your phone bug reports for power. As you might have guessed,
Battery Historian also works great on Android Wear. So give it a go and let
us know what you think. Now, I want to mention
one more thing. In many cases, where
we’re seeing a user not get a full day of
battery usage, it’s often caused by an app doing
some background network processing or location
processing overly aggressively. This is why in future
versions of Android Wear, we’re planning to
put further process restrictions on background
processes and watch faces. This is in addition to
the Android O background restrictions that Griff
mentioned earlier in the talk. And so to prepare
for this, you should make sure to implement
the best practices that I mentioned here today
to get ahead of the game. And always remember to test
your app before you launch it. So we talked about a
lot of things today. And just to give a
quick recap, watches have tiny batteries,
1/10 of phones. Displays are expensive, so try
to reduce interactive display time, implement ambient
mode, use dark color themes, and reduce animation usage. You should also be
careful with network and make sure to avoid
background syncs, to batch your data, and to
use high bandwidth networks for large data transfers. And finally, don’t forget to try
out Battery Historian for Wear. And with that, I’ll hand it
over to David to wrap us up. [APPLAUSE] DAVID SINGLETON:
Thank you, Nancy. So to recap, we’re making
complications and Wear user interfaces much easier to
build, so there’s no better time to get started. Second, as part of
the Android family, we’re getting a whole host of
new features from Android O. So be sure to check those out
and test your app, especially the background limits. And finally, battery
is really precious, so please conserve it using
the tips that Nancy presented. Apart from this session, we have
two more sessions on Android Wear at Google I/O.
So firstly, we’re hosting office hours
at 5:30 PM today where you can ask experts
from the team anything about the issues that you face
or the opportunities that you see while designing or
developing for Android Wear. And second, we have that
other session that Jen already mentioned tomorrow
focusing on the new UI tools we talked about today. And we’ll go through
in more detail the new, simpler
complications rendering system that you can start to
use if you would like to, as well as the new
Wear UI library that we’re open sourcing. Thanks for attending this talk. And if you have any
questions, the presenters will be over in our sandbox
right after the talk, and we’d love to
talk to you then. The sandbox is where you
can see right on this map. Thank you very much. [APPLAUSE] [MUSIC PLAYING]

7 Replies to “Android Wear: What’s New & Best Practices (Google I/O ’17)”

  1. When the update wear 2.0 the moto 360 sport?? A day aprox. in moto sopprt I say this year but not when.. thanks

  2. It's great to see deployment improvements for Android Wear 1.0. However, is does make you wonder how many 1.0 devices are still in use and are not eligible for the 2.0 upgrade. This includes me as I'm still rocking my G Watch.

  3. As a Wear owner since 2014 and now being on my second watch: AW still sucks ass and AW 2.0 feels more like a step backwards when it comes to usability in many ways (removal of bundling of notifications, having to install all phone controlled apps manually after a factory reset, no Whatsapp option in contacts app, no more cinema mode shortcut but three different ways to change the watch face…).

    AW is of course still buggy (I currently need to reset my watch because it started to decide it doesn't want to display notifications anymore all of the sudden even though it is still actively connected).

    And I can't hear anymore that Google Assistant is now on AW when the voice commands feel and work just the same as on previous AW versions! You still use the "Ok Google" command to do the same stuff that you could do before. You still won't get any voiced replies even on watches with speakers for no real reason. You don't have access to new Assistant features like controlling it with the AW keyboard, controlling other apps via Google Actions or changing voice commands ( All of that is not available on AW 2.0. How about you launch Assistant for AW when users actually profit from the features the Assistant provides over normal Google Now Voice Search on phones and the Home platform (which seems to get all the love these days)?

    And why are you guys (at around 4:30 minutes) still trying to sell sending a Whatsapp message via the OK Google command as something new? You can literally do so out of the box since the 1.5 update over a year ago. U should instead work on allowing to send new Whatsapp messages (instead of replying) via the AW 2.0 keyboard.

Leave a Reply

Your email address will not be published. Required fields are marked *