Docs - Create #1625 - Android app support

[upintheairsheep]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

---

Microsoft Reviewers: Open in CodeFlow

[Trenly]

1. What would be the error message if user doesn’t have Windows Subsystem for Android enabled, or is using Windows 10?
2. What would be the error message if ADB isn’t installed?
3. What about android app bundles like AAB/APKS/APKM/XAPK?
4. What would the uninstall process look like?
5. What would the upgrade process look like?
6. Would --scope machine be applicable or inapplicable?
7. What considerations need to be made on the validation pipelines to test APKs? Would the signature of all APKs need to be validated? Would we need to validate a debug cert wasn’t used?
8. What happens when the package conflicts with an existing package of the same name when attempting to install?
9. How would these apps be handled by export

[Trenly]

Suggested change

	ADB (if it ends up being the method of installation)
	ADB (if it ends up being the method of installation)

The spec should define the method of installation

[Trenly]

Which is it - Android, or APK? Specs should be unambiguous.

apk makes the most sense to me

[Trenly]

Wingetcreate information should be a separate specification at the winget-create repository

[Trenly]

This should be disambiguous

[Trenly]

What is AppMoniker?

[Trenly]

I don’t think winget should be bypassing restrictions. If the user has developer mode disabled it could be due to group policy or intune restrictions and sysadmin decisions need to be respected

[Trenly]

PWA or APK?

[Trenly]

How exactly would this featue impact security, more specifically than the blanket statement that there are security concerns?

[Trenly]

I don’t understand what the Pixel 7 or Pixel Tablet have to do with running apps on WSA

[upintheairsheep]

For Windows 10, the error would say “You are using Windows 10. Installation of Android apps requires Windows 11 or higher.” and if not installed: “Windows Subsystem for Android is not currently installed, please install via running this command: COMMAND”. If the user has Windows 11 but no requirements: “Use of Android apps requires 8 GB of RAM or more. Please upgrade the RAM on your computer.”, for CPU “Use of Android apps is not supported on your CPU. Please purchase a new CPU that supports Android apps.” and if using HHD, “Your storage device is too slow to run Android apps. Please upgrade to an SSD.”
“ADB is not installed on your computer. Please run this command to install: COMMAND”
Yes. Other android package files would be supported, including .aab, .apks, .apkm, .xapk, .obb, and possibly .ab.
Uninstallation of applications would either invoke the control panel, or use the adb uninstall command, and the --preserve option in WinGet activates the -k flag in adb uninstall.
The upgrade process is more straightforward, just complete the same process, but use the -r flag to replace the app while keeping user data.
--scope machine may be applicable, we need to run this command as each user account, or make a system built inside of windows to install an android application on all users
If it works, it works. We may need to increase the amount of RAM or install WSA on Windows 11 on them. A debug certificate can be bypassed via adb install -t .
If it conflicts with an Android package, it gives a confirmation dialouge to replace/update the app with -r flag. I’m not really sure about Android apps conflicting with Windows apps though.
I’m not sure I understand what you mean by “export”
I’ll add WinGetCreate docs later.
AppMonkier is the app monkier
I’m saying to bypass the toggle when developer mode in WSA is off by the user. The group policy should be respected, and there could be a policy premitting winget to install android apps exclusively.
I used the PWA support docs as a template.
This may affect security due to malicious APKs via “http” protocol but all http sources should be checked for malware first.
It was just to avoid confusion between the two similar news

[florelis]

@upintheairsheep can you rename the file to have .md extension so it's easier to view here, please?

[florelis]

Also, as a suggestion, I think it may be easier to follow the PR if you reply to each comment separately in the conversation for each one:

[upintheairsheep]

items

I did.

[upintheairsheep]

Hello? Is anyone there?

[denelon]

This seems to be a pair of specifications with APK (Android Package Kit) and PWA (Progressive Web Application). I don't fully understand the WSA( Windows Subsystem for Android) well enough yet to tease all this apart yet. I think we'll need a bit more investigation on our side as WinGet can't install the WSA and potentially a "Store" for APKs to make them available.

I think there may also need to be some additional work to reason about how the upgrade scenario might work.

[denelon]

I think we also may run into cases where there is a "Windows App" and an APK for the same package. We will likely need some settings/preferences to determine which to install in that case. I know there are some existing issues. We should link to those so we can figure out the right sequencing here.

[upintheairsheep]

This seems to be a pair of specifications with APK (Android Package Kit) and PWA (Progressive Web Application). I don't fully understand the WSA( Windows Subsystem for Android) well enough yet to tease all this apart yet. I think we'll need a bit more investigation on our side as WinGet can't install the WSA and potentially a "Store" for APKs to make them available.

I think there may also need to be some additional work to reason about how the upgrade scenario might work.

I used the PWA documentation as a base for this issue. Any writings related to PWAs are outdated.

[upintheairsheep]

I think we also may run into cases where there is a "Windows App" and an APK for the same package. We will likely need some settings/preferences to determine which to install in that case. I know there are some existing issues. We should link to those so we can figure out the right sequencing here.

Just append “-android” to the identifier, and add “(Android)” to the name

[upintheairsheep]

I think we also may run into cases where there is a "Windows App" and an APK for the same package. We will likely need some settings/preferences to determine which to install in that case. I know there are some existing issues. We should link to those so we can figure out the right sequencing here.

Just append “-android” to the identifier, and add “(Android)” to the name

“.Android” may work as well similar to how Geekbench versions are PrimateLabs.Geekbench.5 for instance

[denelon]

I think we also may run into cases where there is a "Windows App" and an APK for the same package. We will likely need some settings/preferences to determine which to install in that case. I know there are some existing issues. We should link to those so we can figure out the right sequencing here.

Just append “-android” to the identifier, and add “(Android)” to the name

I think this will add confusion for users. Someone is going to be in "Dev Home" and search for some popular app and likely not understand the difference between "foo" and "foo-android". I think this falls into the category of:

• Specify InstallerType #1166

We can have a default behavior of the following priority order:

• MSIX
• MSI
• EXE
• PORTABLE
• ZIP
• APK

Then we can allow users to specify via winget install foo --installerType APK for example of those who know what they are doing and specifically want that version of the package. We would also have settings allowing them to change the order of the preferred installer types, or even exclude a set of installer types.

[upintheairsheep]

I think we also may run into cases where there is a "Windows App" and an APK for the same package. We will likely need some settings/preferences to determine which to install in that case. I know there are some existing issues. We should link to those so we can figure out the right sequencing here.

Just append “-android” to the identifier, and add “(Android)” to the name

I think this will add confusion for users. Someone is going to be in "Dev Home" and search for some popular app and likely not understand the difference between "foo" and "foo-android". I think this falls into the category of:

• Specify InstallerType #1166

We can have a default behavior of the following priority order:

• MSIX
• MSI
• EXE
• PORTABLE
• ZIP
• APK

Then we can allow users to specify via winget install foo --installerType APK for example of those who know what they are doing and specifically want that version of the package. We would also have settings allowing them to change the order of the preferred installer types, or even exclude a set of installer types.

“.Android” may work as well similar to how versions that act as different packages like Geekbench and Scratch are PrimateLabs.Geekbench.5 for instance. The installer type should not apply as the packages are separate.

[vedantmgoyal9]

“.Android” may work as well similar to how versions that act as different packages like Geekbench and Scratch are PrimateLabs.Geekbench.5 for instance. The installer type should not apply as the packages are separate.

Denelon wants to say that you can do winget install PrimateLabs.Geekbench.5 --installertype <apk|android> and winget install Publisher.Scratch --installertype <apk|android>. (I would suggest using android because as Trenly said, there is more than one installer type for Android as well (AAB, XAPK, etc.) Using .Android in package identifiers would make the directory structure more nested, which we may not want to do. We will also have to update the search command to search for Android apps specifically.

Edit: Using .Android in package identifiers would make it troublesome to search only for Android packages. Example: Google.AndroidStudio or blueedge.android11react.

[upintheairsheep]

“.Android” may work as well similar to how versions that act as different packages like Geekbench and Scratch are PrimateLabs.Geekbench.5 for instance. The installer type should not apply as the packages are separate.

Denelon wants to say that you can do winget install PrimateLabs.Geekbench.5 --installertype <apk|android> and winget install Publisher.Scratch --installertype <apk|android>. (I would suggest using android because as Trenly said, there is more than one installer type for Android as well (AAB, XAPK, etc.) Using .Android in package identifiers would make the directory structure more nested, which we may not want to do. We will also have to update the search command to search for Android apps specifically.

Edit: Using .Android in package identifiers would make it troublesome to search only for Android packages. Example: Google.AndroidStudio or blueedge.android11react.

Why not just for example 3u.3utools-android

[vedantmgoyal9]

Why not just for example 3u.3utools-android

One of the reasons would be locale metadata duplication, making it harder for moderators to ensure consistency b/w the Windows and Android manifests for the same package. Hence, adding a new installer in the same manifests containing Windows installers would be easier. I don't see any good reason to create a whole new package identifier for the same package, except in cases where we need WinGet to behave in a particular manner.

[upintheairsheep]

Why not just for example 3u.3utools-android

One of the reasons would be locale metadata duplication, making it harder for moderators to ensure consistency b/w the Windows and Android manifests for the same package. Hence, adding a new installer in the same manifests containing Windows installers would be easier. I don't see any good reason to create a whole new package identifier for the same package, except in cases where we need WinGet to behave in a particular manner.

[upintheairsheep]

“.Android” may work as well similar to how versions that act as different packages like Geekbench and Scratch are PrimateLabs.Geekbench.5 for instance. The installer type should not apply as the packages are separate.

Denelon wants to say that you can do winget install PrimateLabs.Geekbench.5 --installertype <apk|android> and winget install Publisher.Scratch --installertype <apk|android>. (I would suggest using android because as Trenly said, there is more than one installer type for Android as well (AAB, XAPK, etc.) Using .Android in package identifiers would make the directory structure more nested, which we may not want to do. We will also have to update the search command to search for Android apps specifically.

Edit: Using .Android in package identifiers would make it troublesome to search only for Android packages. Example: Google.AndroidStudio or blueedge.android11react.

What about .Mobile?

[upintheairsheep]

“.Android” may work as well similar to how versions that act as different packages like Geekbench and Scratch are PrimateLabs.Geekbench.5 for instance. The installer type should not apply as the packages are separate.

Denelon wants to say that you can do winget install PrimateLabs.Geekbench.5 --installertype <apk|android> and winget install Publisher.Scratch --installertype <apk|android>. (I would suggest using android because as Trenly said, there is more than one installer type for Android as well (AAB, XAPK, etc.) Using .Android in package identifiers would make the directory structure more nested, which we may not want to do. We will also have to update the search command to search for Android apps specifically.

Edit: Using .Android in package identifiers would make it troublesome to search only for Android packages. Example: Google.AndroidStudio or blueedge.android11react.

—installertype should only be for EXE, MSI, MSIX, APPX that are of the same version of the package.

[vedantmgoyal9]

Well, then a flag --android or --only-android can be added to search command, but the underlying searching algorithm would be based on InstallerType only.

[upintheairsheep]

You know we can just add apps only available for Android for now, with no Windows version available on that app. Seriously, how did this thread go downhill?

…

On Sunday, June 18, 2023, Vedant ***@***.***> wrote: Well, then a flag --android or --only-android can be added to search command, but the underlying searching algorithm would be based on InstallerType only. — Reply to this email directly, view it on GitHub <#3267 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKNKRXGH26ATXU2PH2KBYFLXL5ONHANCNFSM6AAAAAAYMWI3O4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[upintheairsheep]

Merge?

[yao-msft]

Merge?

Hello @upintheairsheep,

We usually merge spec after or near when implementation is done. There may be unknowns or changes needed during the actual implementation. So we'd like to leave this pr open for discussion and it could be extended to include future dev spec.

Thanks

[upintheairsheep]

Well, then a flag --android or --only-android can be added to search command, but the underlying searching algorithm would be based on InstallerType only.

Good idea. But would require the interactive only thing to be done.

[upintheairsheep]

Additionally, it is important to note that not all Android apps have Windows or PWA versions of themselves.

[denelon]

We're doing work on "InstallerType" in the client for filtering as a part of WinGet download. I'm sure that will accrue to the work here.