I think that statement from Intel has to be taken in context; that technology is for enabling Android applications which are not otherwise executable on Intel CPUs to successfully run on Intel devices. Its not an assertion that Java-based Android apps won't be available in the app store; its just saying "these apps which are generally really hard to get running on x86, we've got those covered too".

This was my interpretation of the statement too. Specifically what comes to mind is apps that depend on native/shared libraries that only have an ARM build and not a x86 build shipped.

My guess is that apps written in java/kotlin are easy to run in a x86 compatible android runtime.

The difficulty is for native code, the arm libraries embedded in many apps. Actually most Android app depends on native libs. For image processing for example. Nearly all games are using native arm binaries.

The sentence you quoted is probably related to native code only, which is the difficult part. It looks like they have some magic tricks to make them work on x86 architecture with having to recompile the libs.

Intel used the same tricks in their x86 android devices a few years ago, you could run arm native code on their x86 android versions transparently.

Intel used to call this Houdini. It was also used in Android-x86. Last I looked at the Android-x86 sources, binfmt was used to configure certain types of binaries to be translated on-the-fly by Houdini before running the translated x86.

Houdini.. I hope it doesn't escape its locked sandbox

oh this makes more sense: JVM apps run in Windows with some simple JVM container. Intel Bridge Technology is only needed for the apps that have compiled native code.

> some simple JVM container

no, there's a new NT subsystem to support this: Windows Subsystem for Android, and as you could guess from the name, it is somewhat related to WSL.

the NT kernel was always designed to accommodate multiple subsystems running at once. Until WSL, there was only ever the Windows subsystem itself. soon there will be a third subsystem one can install.

this is neat, to me.

WSL is very different than NT subsystems (it's based on drawbridge). And NT did support a fourth (or fifth depending on how you want to count it) POSIX subsystem for quite a while, but that's different than WSL.

And interestingly enough, Android support was the original purpose of WSL. It was modified to run an Ubuntu user land on original release for some Microsoft product reason. It's nice to see it coming back in it's original form too.

There was a Linux subsystem for NT around early 2000s in Microsoft Research.

There is amazing depth inside parts of Microsoft. For example, a team built Xbox360-on-PC sometime around 2007-08. That was emulating the PowerPC and GPU on Intel PCs. This didn't ship for various reasons as a product, but it was in the draw when Xbox One came along and they wanted game compatibility between Xbox 360 and XBox One.

WSLv1 was built on Drawbridge that originally came from MSR. I heard a rumor that WSL was spun out from a project using Drawbridge to run Android. Obviously a lot of work went into WSL subsequently, but the pieces to get started were in place.

There was a posix subsystem as well in the early days, however it lacked functionality and was used as a “check that box” for procurement rather then functionality

Windows is "POSIX compliant" still, whatever that is worth. Are you sure that was a subsystem?

Also OS/2 (1.x).

Hmm, but WSL2 just runs a VM instead, right? Given that I'd have expected WSA to be a container on the WSL VM, running something similar to Anbox.

WSL2 runs in a VM with host OS integration, and I assume this is how the subsystem functionality of the NT kernel is used in WSL2.

WSL1 is the "Linux as a subsystem of Windows" thing I described.

Note that WSL2 is not a complete upgrade from WSL1, and WSL2 does not render WSL1 obsolete. They each have strengths that the other does not.

Android apps don't ship with JVM bytecode, though; they are compiled to the DEX format[1], which is the format used by the Android Runtime (ART), which is generally why these Android-in-container projects ship the whole bionic-based userland and pipe I/O through a bridge service.

[1] https://source.android.com/devices/tech/dalvik/dex-format

I'm guessing Intel Bridge Technology is related to what they used to call Houdini. Houdini is an ARM binary translator which translates ARM binary code into x86. I believe Android-x86 (https://www.android-x86.org) makes use of it.

Based on the trends I'm seeing, they better be working on the opposite direction ;)

Quite the contrary. Why would Intel want x86 on ARM? That would make migration even easier.

> How many Android apps out there are not written in Java?

A fair few games are developed in C++ and run through the Android native interface. Unity games, often written in C#, run on Unity's native runtime which has been ported to Android.

Intel Bridge Technology is, presumably, a way to get ARM binaries running on x86 by AOT compiling them. It is not necessary for Java or Kotlin apps or native x86 apps, so those will run without IBT.

Yes. All apps in Android are spawned from the Zygote, but once started an app is free to call as much native code as it likes.

https://medium.com/@voodoomio/what-the-zygote-76f852d887d9

Also apps that use React Native, as the RN runtime is written in C++ and uses the NDK on Android.

There are few categories of apps this targets.

“Clubhouse for Android” category: avant- grade apps that launch first on Android or define android platform. Nonexistent.

“Median phone user ecosystem:” The TikTok Facebook, Instagram, WhatsApp, YouTube, Snapchat, China app ecosystem and India app ecosystem. The experience of all these is bad on Windows browsers or unavailable.

”Games”: hard to say, because Windows is a better platform for games than Android by 10x.

This doesn’t sound very strategy driven. If it’s UX driven, hard to see how it competes with the median user getting an iPhone. This is the case with the consumer in China, where despite 30 Android app stores and lots of innovation / competition the iPhone is still preferred by those who can afford it.

The strategy here for Microsoft is pretty obvious. Windows is becoming a tablet OS first and foremost. However it is at best a 3rd target for app developers, once they have finished their iOS and Android versions.

Natively supporting an Android app store allows them to get apps so users will want to buy the hardware, which in turn generates market share that gets developers interested.

Even in Windows 10, on hybrid laptops it is already a better experience than most Android tablets.

Around here when people aren't carrying an iPad, they are most certainly carrying either a Surface or a foldable Windows laptop.

> ”Games”: hard to say, because Windows is a better platform for games than Android by 10x.

Note that there are quite a few commercial "Android on PC" emulators already, e.g. https://www.memuplay.com/, https://www.bluestacks.com/ and https://www.bignox.com/.

In terms of scale, Bluestacks claim they have 50 million monthly active users which makes them pretty substantial! From https://www.bluestacks.com/promote-your-game.html. Overall mobile gaming revenue is now larger than console gaming and more than 2x PC gaming, and rapidly growing (https://scaletech.medium.com/mobile-gaming-statistics-trends...). Android gaming is a much bigger market than you'd imagine, especially for the younger generation.

> hard to see how it competes with the median user getting an iPhone

> This is the case with the consumer in China, where ... the iPhone is still preferred by those who can afford it

I think you're seriously overestimating how popular iPhones are, even to users who can afford them. Especially if you're looking at Windows users, Android is hugely dominant outside the US.

In China for example, iOS market share is actually constant around 20% or maybe slightly declining over the last decade (https://www.statista.com/statistics/262176/market-share-held...) despite the huge increase in average purchasing power, which makes it seem unlikely that the only thing holding people in China back from them is the price.

Globally, Android is at 70% of devices (https://gs.statcounter.com/os-market-share/mobile/worldwide) even in relatively wealth areas like the EU. iOS is primarily popular in the USA (where it's about 60% of devices). I suspect iOS and Mac usage are fairly closely correlated, so the Android percentage goes up substantially if you're only looking at Windows users. I think Android integration actually makes a lot of sense for Microsoft!

I use Bluestacks to run home automation programs.

It subjects me to ads for third-rate games that I can't imagine people play. First-tier Android games like F/GO and Genshin Impact seem to be disabled on non-phone devices, particularly Bluestacks and Android TV. I see a huge amount of fan art from those games, but I wonder if gaming on Bluestacks is just a Potemkin Village.

One example: Freefire is one of the largest mobile first person shooters with more than 100M monthly active users. "Pro" players and streamers tend use to BlueStacks.

It's probably more that Genshin Impact has an actual Windows client than any indictment of Android emulation.

Bluestacks is a scam, they use your VM to gin up download counts for its customers, app developers.

I wish most win users were ok with android emulators because they are great. Performance is fantastic. But 99% of users refuse to take the extra step of first installing an "app to run an app". Windows could have as easily integrated one of these emulators into the OS which would have allowed for using Google services (unsure about legality of this) but they have chosen to compete with Google which isn't a bad thing since it improves competition

> In China for example, iOS market share is actually constant around 20% or maybe slightly declining over the last decade

So a user count comparable to 100%+ of the US phone user population?

Yes - but meanwhile Android at 70% of global mobile users (~5 billion people) has an install base more than 10x larger than the entire US population.

It is not a small market, there's (I assume) a good correlation with Windows users, and it's not a bad idea for Microsoft to be looking at potential integrations here.

There are some high quality creative apps on Android for things like photo editing, drawing, video editing etc. This could disrupt the space in which Adobe currently operates. Android could add a lot of diversity to windows in terms of productivity and creative apps.

I think a possible advantage is also integration with Teams and OneDrive. Aandroid apps don't tend to use file stored in directory structures. You use the share menu instead and maybe some pickers for photos and downloads. This could integrate well into their cloud ecosystem. Save app data to OneDrive and have sharing menus work between the two. You could even have tabs in teams that show an Android app and store the data in the team. Corporate IT departments might prefer that to voluminous directory structures and vendor management.

Android apps running on windows to compete with adobe apps built for Windows...you must be kidding!

I for one can't wait to run my little hobby app that I develop for Android on Windows, sounds like fun. I agree though, many typical users will not use this except for the categories you lay out. But I do think that "Median phone user ecosystem" may be bigger than you think - India and China are not small markets.

I would expect Android apps that are written in Java would also run, but they wouldn't use "Intel Bridge" to do it.

>those not written in Java or compiled to run natively on Intel-based devices - to run on those devices

I think they mean non-x86 binaries e.g. ARM, Would still be interesting to see how the translation happens it's not like MS/Intel has silicon level advantage like Rosetta/M1 but for translating other way around.

>I was expecting a full VM / emulator, but this doesn't sound like that.

Even Google did not consider VM/emulator, The went for Android Runtime for Chrome (ARC) and then after learning that it doesn't support all features they switched to containers.

There is the android NDK (Native Development Kit) it's mainly games or CPU intensive apps trying to get as much performance or software that was ported and whose code base was primarily a compiled language like C.

https://www.theverge.com/2021/6/24/22549303/windows-11-intel... reports it will work on AMD CPUs too.

> According to Intel, Bridge itself is a run-time post compiler that translates applications that are compiled for non-x86 platforms (in this case, Android applications) into x86 instructions (which can run on Windows 11 with Intel or AMD CPUs).

Apps might be written mostly in Java but have one native code library for encoding, audio, etc. That’s enough to break the app without some bridging such as this.

I'm hoping to get an AMD PC sometime in the future. I hope this works on more than just Intel processors.

If microsoft is working on it I bet they would want it to work on AMD CPUs as well.

Yes it works on any x86 cpu with nested virtualization and VT-d (anything post sandybridge?).

> For that matter how many apps are targeting Android devices with Intel CPUs anymore?

Pretty much none, but I expect most devs are developing/testing on x86 Android emulators, since they're developing on x86 systems.

Probably the same binary translation tech that was used in Intel based android phones back when Intel made a push for that.

I feel like that’s Rosetta 2 for PCs.

> How many Android apps out there are not written in Java?

Lot of apps use natively compiled libraries through NDK.