HAMZA USMANI: Hi, folks. Thanks for joining us.
Today, we're going to be talking
about Windows Subsystem for
Android and what it enables for Android developers.
I'm Hamza Usmani, a Program Manager at Microsoft.
ANDREW LEADER: I'm Andrew Leader,
also a Program Manager at Microsoft.
HAMZA: Andrew, what if I told you you could expand
your Android app's Total Addressable Market to
millions of Windows devices without rewriting your app?
ANDREW: That sounds amazing.
I wish I had some way of doing that today.
HAMZA: Well, you do.
Windows Subsystem for Android lets you do exactly
that, and lets you run
your existing Android apps on Windows 11.
So if you're a developer looking to expand
your app and the reach of it to new form factors,
devices and untapped markets,
Windows Subsystem for Android can help you achieve that.
ANDREW: So I can easily run
my Android app on Windows without rewriting it?
HAMZA: Exactly. We'd love to show you
how easy it is for an app developer to get
an Android app available on Windows simply by
optimizing and submitting to the Amazon Appstore.
By submitting your app to the
Amazon Appstore on Windows,
you can have your Android app
available to users who already
spend hours every day in front of their Windows devices,
enabling scenarios and use cases
that you might not previously have been able to reach.
From a user's point of view,
how awesome would it be for me to have
my favorite mobile game or app open on one of
my desktop monitors during
my regular work streams
without having to pick up my phone?
Once your app is available on
Windows 11 devices in the Amazon Appstore,
a user with an Amazon Appstore account and
the Appstore installed on their device
can download and run it as usual.
We should note though that Windows Subsystem
for Android is currently
in public preview and available only in the U.S. market.
Developer participation in the Amazon Appstore
on Windows 11 is
currently part of a closed beta
and only open to a selection of apps.
We look forward to opening this up to
all developers as we expand over time.
Let's take a look at how
installing the Amazon Appstore works.
Here, I have the Microsoft Store
open to the Amazon Appstore page.
You can see that users can
discover Android apps in the Microsoft Store,
such as in this Recommended Appstore Apps section.
We can see Kindle,
The Wall Street Journal and a ton of other apps.
Let's go ahead and install the Amazon Appstore.
Installing this will silently
install the Windows Subsystem for Android on
your Windows 11 device, and voila,
just like that, we've installed the Amazon Appstore.
Since this is the first Android app
we're launching on this device,
you can see the Windows Subsystem for Android
initializing. Now that we're
signed into the Amazon Appstore,
let's go ahead and install an app.
I want to download Kindle.
Just like that, I have Kindle available on my device.
Now, let's go to Mario to talk about the Amazon Appstore.
MARIO VIVIANI: Thanks Hamza. Hi, folks.
I'm Mario, Head of Developer Evangelism at Amazon.
The Amazon Appstore is finally now
available on Windows 11 devices to
all U.S. based customers.
In this current public preview phase,
we have released over 1,500 games and
apps across a variety of categories like entertainment,
news, weather, sports, and many more.
As new apps are constantly being
added and as we expand into new locales,
the Appstore will add
hundreds of thousands of new applications.
If you already have an app within the Amazon Appstore,
you're in great shape
leading up to general availability and
we'll learn how to connect and debug
your apps in the upcoming slides.
Instead, if you have not
submitted your app yet and want to unlock
new customer base with the reach
in the hundreds of millions of customers,
scan the QR code here or input the short URL
you see onscreen to sign up for the program updates.
While you're there,
browse technical documentation, how-to
videos, and explore what
new features the Amazon Appstore has
to offer you. Making your app discoverable
across two stores has never been easier.
HAMZA: Now, here's how you can
connect and debug your app on Windows.
As an Android app developer,
here's what you need to do to
connect to the Windows Subsystem for
Android Virtual Machine and optimize or debug your app.
First, you must meet
minimum Windows 11 requirements,
as well as the main specs you see here on
the screen, and be using a Windows 11 device in the
U.S. region with an Amazon Appstore account.
After that, simply install the Amazon Appstore from
the Microsoft Store, and that will automatically
install Windows Subsystem for
Android, as well as the Windows Subsystem for
Android Settings app.
To test and debug your app using ADB,
Android Debug Bridge, you have to connect to
the Windows Subsystem for Android Virtual Machine first.
The Settings app is where you can enable
developer mode and find the IP address of
the virtual machine to connect to.
For a valid IP address to appear,
you must have an Android app running on
your device, such as the Amazon Appstore.
After that, simply run an ADB connect
command with the IP address, and you can now
install and sideload debug
your app on Windows Subsystem for
Android as you would with
any other Android device by using an ADB install.
Let me show you how easy this is.
First, ensure you have an Android app running.
We have the Amazon AppStore app running here.
So let's go ahead and open up
the Windows Subsystem for Android Settings app.
We have developer mode on, and
we have an IP address available to us.
Let's copy this. Going over to command prompt,
we can run an ADB connect command with
that IP address to connect to the virtual machine.
Just like that, we're connected.
We can now perform a streamed install of
this APK that we have of TwoNote.
Let's go ahead and do that.
You can see that we've now just installed
TwoNote on Windows Subsystem for Android.
For developers that primarily work in Android Studio,
we have great news.
Windows Subsystem for Android is
recognized as an Android device.
This means you can run,
test and debug your apps directly from Android Studio.
All you have to do is connect to
the virtual machine using an ADB connected command.
Once we're connected and we go back to our app,
we can see Windows Subsystem for
Android show up as the launch target.
We can go ahead and launch our app.
Just like that, we can debug our app
right here within Android Studio
on Windows Subsystem for Android.
ANDREW: Now, while you don't
need to change your code to bring
your Android app to the Amazon Appstore on Windows,
there are some best practices that can help you
optimize for the best user experience on Windows.
First, let's hear from Mario about how to determine
app runtime what store services your app should use.
MARIO: If your application depends on
services from other app stores,
you will need to use
getInstallerPackageName to
identify where your application comes from.
This lets your application surface the services that you
want, rather than relying instead of the device type.
If your application is downloaded on
Windows 11 device from the Amazon Appstore,
it will return the installer as shown here on
the slide with the string, "com.amazon.venezia."
This string will alert you to use Amazon services like
in-app purchases and
EDM and other services that Amazon supports.
ANDREW: Thanks, Mario. Now, let's talk about
another best practice: optimizing
your app for windowing and resizing.
Android apps on Windows run
in their own resizable windows,
just like other Windows apps.
This means you should consider how your app
works at really small sizes down to
586 density-independent pixels,
and up to really big sizes
like when on ultrawide monitors.
By default, your app launches with
an initial window size of 1280x720,
and when the user resizes the app,
the last window size will
be remembered for the next launch.
This default behavior likely works great for most apps,
but if your app is best experienced
at a different starting size,
you can modify your initial window size
by either specifying
your preferred window size in your manifest,
or by using dynamic launch bands to
programmatically specify your starting size.
Android apps are also resizable and can
participate in Windows 11 features like Snap Assist,
where users can easily arrange
their windows into productive layouts.
Additionally, your app's display density might
even change when users move windows from
one screen to another in
multi-monitor setups with different display densities.
Let's take a look at how to
support resizing in your app.
As we can see
in our sample app,
the UI responds well to resizing.
But if I type in something and resize the app,
the text is lost because my activity doesn't restore
the text from the activity bundle,
and the text disappears.
For most apps, there's an easy way to fix this.
I'm going to open my Android manifest and add a config
changes declaration.
This basically says, please don't restart my activity
when the following configuration changes happen.
For example, when the orientation changes,
or the screen size changes,
my app's activity will no longer restart.
It's important to include all the values seen here,
especially the smallestScreenSize value,
which only triggers when resizing across
a 600 DP size, and
the touch screen value, in case the user drags
your window to a non-touchscreen monitor.
So we can deploy our app and after making these changes,
we'll see that the text no
longer disappears when resizing the app.
As we saw on the demo,
for many apps that are already using
responsive layout controls like
constraint and linear layout,
to support resizing without restarting,
your app should simply be able to specify
the config changes your app handles.
However, if you want your app to not
resize and instead be placed into compat UI mode,
you can specify a re-sizable activity to be
false on your launch activity
or at the application level.
When a user resizes
an Android activity that isn't re-sizable,
the app's content will be scaled,
and if the aspect ratio has changed,
the app will be letterboxed and
a restart to resize button will appear.
Let's see an example of this.
So let's imagine our sample app has a lot of complex UI
that's difficult to get working with dynamic resizing.
A simple way to make
our app work on Windows without the whole app
restarting when it's resized is to
simply specify re-sizable activity false,
and when we deploy our app like that,
what will happen is when you resize the app,
instead of actually resizing and restarting the activity,
it will add letterboxing and it will actually
scale your app and this little "Restart" button
will appear, informing the user that they
can restart the app to fill the window,
but that will restart the app.
So, really quick and easy way to get your app working if
it's really complex to support full resizeability.
HAMZA: Now, let's take a look at
the different input devices developers should
consider when bringing their apps to Windows.
When it comes to input methods,
Android apps on Windows should
consider keyboard and mouse as
the main input methods alongside touch and
pen to ensure the best user experience.
This means accounting for
several keyboard and mouse-specific events.
Many existing Android apps already support keyboard
input and keystrokes for common use cases.
As an example, some games may already
support movement facilitated through the "W",
"A", "S" and "D" keys alongside touch input.
For keystrokes that aren't
anticipated by the Android framework,
apps need to handle that behavior themselves.
Keystrokes such as the "Enter" key for submitting
text input navigation in an edit text field,
"Arrow" and "Tab" key navigation to toggle
through elements, and control based shortcuts
such as "Ctrl+Z" and "Ctrl+Y"
for "Undo" and "Redo" within apps are
just some scenarios that you should
consider when optimizing your app for Windows.
If a text control is focused,
Windows Subsystem for Android
injects characters translated using
the Windows keyboard layout via
a hidden Android input method editor.
If your app uses custom text controls,
you should ensure that these are
following Android best practices.
So for example, when a user
navigates an app using the "Tab" key,
the input focus is passed between elements in the order
that they appear in the layout.
Let's take a look at that.
Here, we have a sample Android app to display navigation.
This Android app has five buttons,
as you can see, and we have the layout open on the left.
Let's use the keyboard "Tab"
key to navigate through our app.
As you can see, focus is passed from one button to the
next in the order that
the buttons appear in the relative layout.
Let's go ahead and tweak our layout a little bit.
Let's add the next focus forward
Android attribute to all of our buttons.
This attribute will help us specify an ID
that we want the focus to shift to when we press "Tab".
Let's go ahead and relaunch our app now.
Here's our app now running with
the next focus forward
attribute added to all of our buttons.
As we press "Tab",
you can see that focus
is passed from one button to the next,
but in the order that we specified.
So from button one to two,
two to three, four and five.
In terms of mouse input,
similar to keyboard input,
many scenarios are automatically covered in Android.
Scroll wheel actions,
dragging and selecting to highlight with
the mouse are often automatically supported.
Windows Subsystem for Android reports mouse down,
move and up events as touch events by default
for compatibility with most apps that expect touch input.
For pinch to zoom gestures on
the trackpad or control and scroll on the mouse wheel,
the subsystem will inject touch input to
emulate a pinch to zoom gesture.
If a text control is focus,
then the input is reported as a mouse input to ensure
text highlighting and cursor placement
follows common mouse paradigms.
However, developers might want
to include optimizations for
specific actions like
mouse button clicks and pointer hovers.
Pen is supported as well,
including pressure, tilt,
orientation, eraser and the pen button.
Apps that support Android stylus input
will just work with Windows Pen input.
Let's take a quick look into how Android
notifications are handled in
Windows Subsystem for Android.
ANDREW: Android apps can send a variety of notifications.
Windows Subsystem for Android
handles all these as you'd expect,
and mirrors them as Windows native notifications.
This means that notifications appear and stay
in the Windows notification sidebar as expected,
and users can interact with them
as they would on an Android device.
Let's take a look at how that looks on Windows.
We built this sample app to illustrate
notifications and how they appear on Windows,
so this is just a basic Android notification.
As you can see, it comes in and looks and
feels like a normal Windows notification.
Image notifications also work,
so I will show you what an image looks like.
Another cool scenario is
download, like progress bar notifications.
So let's see what that looks like.
And as we can see, the progress bar is
updating, and I'll show you the code just to show you
that this is 100 percent
normal Android notifications, and we
didn't have to do anything to
tweak the app for Windows.
Finally, the last type of
notification that's really neat is
notifications with buttons like
even quick reply notifications.
So I'll pop this, I'll go ahead,
close the app and say hi
and we'll see that our app gets activated with the text.
HAMZA: Now, let's talk about APIs and services.
For Android developers with
apps already on the play store,
there are some differences when it
comes to supporting your app on Windows.
Amazon provides a useful suite of APIs, services,
and features to modify your Android app to enable
it to work with the Amazon Appstore on Windows.
For example, billing and cloud messaging
are Google Play APIs and
services that your app might rely
on, and Amazon provides services such as Amazon
in-app purchasing API and
Amazon device messaging for you to use.
If you're using Firebase in your app
and you want to continue using Firebase,
you might need to implement some changes as
the native Firebase SDK
is dependent on Google Play Services.
Instead, we recommend using
the Firebase JavaScript SDKs instead,
which are supported in the Amazon Appstore on Windows.
Most Firebase JavaScript SDK features
are supported, and there are plenty of
alternatives for unsupported features such as
for in-app messaging or Crashlytics.
ANDREW: We've now covered many of
the common best practices
that you as an Android app developer,
may need to know when bringing your app over to Windows.
For example, how to detect when to use
the Amazon Appstore services, and don't
check the device manufacturer, and
also windowing and resizing considerations,
new input methods such as mouse,
keyboard and pen, and more.
With all these optimizations,
you can easily enable your app for
a great desktop user experience and have it
available to millions of Windows users.
As we look to bring the Windows Subsystem for Android out
of public preview into the general public in the future,
more and more users will be looking
for their favorite apps on Windows 11.
We hope you're just as excited as we are to enable
new experiences and grow
the reach of your apps to new customers.