Application Development with Windows Subsystem for Android
Microsoft has opened testing Windows Subsystem for Android. For now, this is available to beta testers in the US. But the craftsmen have already found ways to install it on any assembly of windows 11. Next, I will describe this instruction, and run the applications from Android Studio, try to debug it and tell you the nuances that I noticed that you need to pay attention to when developing.
First, you need to make sure that the CPU supports virtualization and enable it. Open the “task manager”, go to the “performance” tab under the CPU graphs, look for the line “Virtualization enabled”. If there is a line, everything is OK, go to the next step, if not, we climb into BOIS and turn it on there. If the CPU does not support virtualization, then close the instruction, it will not be useful.
The next step in the search for the “Start” menu is to look for and open “Enable or disable Windows components”, and put a checkmark in front of the item “Virtual machine platform”
Next, you need the Windows Subsystem for Android installer, there are instructions on how to get it from the Microsoft Store server, but I didn’t succeed. Found a link to Google drive
Next, you need to start PowerShell necessarily on behalf of the administrator! Enter the command into the console
Add-AppxPackage -Path "C:Usersuser1DesktopMyApp.msix"
Where we indicate the path to the file downloaded in the last paragraph. If everything is successful, then a link to Windows Subsystem for Android appeared in the start-up.
Now let’s look at how to install apk files on this system. First, launch Windows Subsystem for Android, turn on developer mode, click the icon next to the “Files” item to start the subsystem. Go back to the previous screen and click the “update” button next to the “IP address” element. On my screen, this button is already called “Copy”, because I have already pressed “Update”.
The resulting IP address will be used to connect using ADB. To do this, enter the command in the command line
adb.exe connect полученный_IP
From this point on, Android Studio sees the subsystem as a device on which to run applications. Note, if AS was not started or another project was opened, then in order to see the subsystem as a device, you need to re-execute this command
I started all the applications that I tried to launch. Debag works without problems, just like on the emulator.
If you need to install the APK file, then enter the command through the command line
adb.exe install MyApp.apk
After installing the application in any of the ways, a shortcut for this application appears in the Start.
Now my observations:
If we understand that it will be necessary to support a desktop application, we need to pay attention to the processing of the physical keyboard. For example, there were articles about adding navigation to the RecyclerView with arrows
Even more acutely noticeable is the problem of the lack of handling of the “enter” button in the TextView
There was a dispute with a colleague that armv7 will not be supported here. For the test, we launched an application using exoPlayer to display streaming video – everything took off without problems, it works. So “sishnye” libraries are not scary
If the orientation of the activity is not locked in the manifest, then the application can be resized without any problems, while at each resize all life cycle methods will be worked out as expected, if it is locked, then the window size will be constant, in aspect ratio approximately like on the phone
The physical camera is picked up without problems, if not, an empty window opens
After all these actions, the emulator stopped running for me and until I figured it out (if someone repeats it and figure it out – write in the comments)
I think this is a cool subsystem. It is clear that it is still raw, that there are problems with Google services, but in the future this is a cool groundwork for developing applications for two platforms. What do you think about this?