Want to highlight one paragraph from that description: "Intel Bridge Technology is run-time post compiler that can be integrated into Android-in-Container to enable certain Android apps – those not written in Java or compiled to run natively on Intel-based devices - to run on those devices."
How many Android apps out there are not written in Java? I'm guessing Kotlin isn't supported either. For that matter how many apps are targeting Android devices with Intel CPUs anymore?
I was expecting a full VM / emulator, but this doesn't sound like that.
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.
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.
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.
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
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.
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.
> 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.
“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.
> 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!
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.
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
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.
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.
>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.
> 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.
Some years later everyone will realize that desktops are not phones and are meant to utilize more available screen space. Then everyone will come up with "revolutionary" desktop interface ideas and we here at HN will call it out that we already had these back in 90s.
I am waiting for that time. Windows 10 is "phony" already and becoming more like it's built for people with low vision. I hate it's UI. I hope bringing android in windows don't turn into another Electron.
Now you'll have UI elements from Windows 3.1, Windows 95, Windows XP, Windows 7, Windows 8, Windows 10, Windows 11 and Android all in a single operating system!
Can't wait for the Android Settings integration to Control Panel next...
> Some years later everyone will realize that desktops are not phones and are meant to utilize more available screen space.
Keep in mind there's plenty of android apps designed to function on tablets with much larger screens. Obviously there's not nearly as many as on the iOS side of the world where the iPad is far more successful, and there's a wide variability in how good they are at taking advantage of the extra real estate. But they're out there.
The real issue, IMO, is that those apps are designed with a touch-based UX, and that doesn't translate well to mouse-based interaction. And one of the few areas where Apple and I are in agreement is in poor ergonomics of a touchscreen on a laptop or PC.
And now days every desktop app is made as if "mouse" doesn't exist. Or as if `market research has shown that bigger buttons engage more users`. I like to see more on my screen in one go.
That's why we get multiple monitors or bigger monitors. To see more content.
And everyone is hellbent on wasting it. More CPU/RAM got us more web-as-desktop apps. Higher resolution, bigger screens are giving us bigger, emptier GUIs.
That said, I assume it will be possible to run Android apps in their own windows. No need to force the entire OS into some weird Android mode. It'll likely work the same way WSL does.
That already happened once, that's how we got Windows 10 after the tablet-first travesty that was Windows 8. And I agree with you, we'll likely see it happen again.
We should note Amazon's android store has been aimed at Fire tablets for years now (Amazon's phone was really a flash in the pan).
Sure the ecosystem is far from being mature, but it is also progressively benefiting from chromebook integration, and hopefully from this windows integration.
I use Windows 10 every day, and I think the days of the desktop UI mattering are over. 95% of my time is in Chrome and Steam games. Windows already has split screen and that's enough for home use.
If anything, Amazon knows this will really incentivize updating your Android app on the Amazon App Store, or bringing it there if you haven't.
And that's good for us because, should the Amazon App Store become more viable for manufacturers, Google might find themselves increasingly losing control of Android, and increasingly forced to make the Play Store more competitive.
That's good to know. One of the things that pushed me completely off Android was discovering how few even Microsoft apps I could use without Play Services' malware being installed as well.
And it's very likely Google will find ways to retaliate against Microsoft for working with the Amazon Appstore here. They are pretty aggressive against forks. Honestly, I would suspect the next Duo won't be able to run Play Services, because Microsoft dared to work with a competing Android app store.
Plus it counters Apple, which recently made iOS apps available on macOS.
Seems like all the major OS are betting that mobile is going to be the focus of future native app development and don't want desktop users to miss out.
Apple being vertically integrated with its own ecosystem versus third parties integrating it on non native CPU platform sounds like a very different level of integrity.
No one can match the level of integration Apple had made on Windows and Android platform.
We'll see what kind of limitations and bugs to show up.
This could be good for competition, but it's hard to see it as being about innovation.
Same as Microsoft copying Chrome and calling it Edge, users have another browser, now with MS telemetry etc. instead of Google. Good for user choice but hardly innovation.
What is number of tablets? The total number of shipped Tablet? Why would it matter if those tablet are not in use? Which is what the stats from Stats-counter are showing.
Market share is how much money you make. So for example if apple sells 1M ipads for $500 and android tablets cost $50, at 45.57% it would mean there are 9M android tablets sold. Which makes the proportions more like 11% ipad / 89% android.
Yeah I don’t think it’s really taken off. The iOS apps that I would actually like to use on my M1 Mac have just opted out - not sure why.
For MS I think this could be a modest low risk win, even if it doesn’t massively take off. It gets them at least some tablet apps, and some popular social apps for desktop, without having to incentive developers to port them.
Initially all ios apps were automatically included. But the latest version of xcode requires building with macOS as a destination which in my experience just doesn't compile. And I don't have the time to find out why (neither does my dev community). So for example, my app was available on m1 for a while, and as soon as I updated from new xcode, got opted out
Amazon's App store as it stands now is a bit of a ghost town. If apps are on there at all they're often outdated versions. I assume Google won't agree to cooperate with Microsoft and let the Play Store be supported. Anti-trust should help with that kind of monopolistic play but lol.
Google's well on their way to replacing Android, no? I thought a lot of their announcements at events the last couple years had been about their from-scratch Android replacement.
Maybe another big company will pick it up, but if not, I don't see much benefit to the hobbyist community over the current status quo if Android gets "opened up" more but also loses 99+% of total corporate backing toward its development. Even if Amazon or MS run with it (and maybe that's what this is the beginning of?) that seems more like an on-life-support scenario than one with a bright future for Android.
Could go totally differently if major phone and tablet manufacturers ignore the New Shiny Thing and stick with Android so developing commercial software for it remains viable, I guess.
I don't think Google is in a position to "replace" Android. They simply don't control the hardware; they can ship Fuchsia to their Home assistants and thermostats, but when it comes to phones and personal computing devices, they don't have many cards to play (beyond Pixel, like 0.5% of the Android market). The power lies with hardware manufacturers and developers.
Their new wearables partnership with Samsung may help here. Maybe Samsung would play along with a new Fuchsia phone OS. But there's still the developer issue; any new OS like this would need Android-backward compatibility support exactly similar to what Microsoft is doing here. "Android" in this sense doesn't mean "the OS"; its the application system.
What's happening in the Android world right now is so healthy and excellent, I almost can't believe its the product of Big Tech. Google is already pushing Android apps on ChromeOS, now Microsoft has them on Windows, through the Amazon app store, and nowhere in any of this is the actual Android Operating System. The comparison here isn't Android vs iOS vs Windows; its Android vs Flutter vs Web. Its a new way of writing "native"-adjacent multiplatform applications; the OS doesn't matter anymore.
Sure the touch-friendly UI will suck in some applications, on some deployments of Windows. That's not Android's fault; its on the developer to recognize the input method and canvas size, and adjust accordingly. I hope more do!
Right, but if no-one picks up the torch of maintaining and developing Android and giving it away to device manufacturers, I'd imagine going with the new Google OS that they are going to do that for, would be very tempting. Most phone manufacturers haven't shown an interest in putting a ton of work into the Android, themselves, even just to customize it beyond adding some shovel-ware and maybe a theme (notable exception: Samsung)
Possibly the app ecosystem will survive, even if the OS itself withers into obscurity, provided Fuscia can run Android apps (seems likely, but I haven't kept up with news on that sort of thing)
When/if Google ditches Android you think they will give up the echo system? You think suddenly Android apps wouldn't run on Fuchsia?
It would be a seamless transition(look at how they did it on the Nest Hub).
All the "cool" new Google features and performance upgrades may be Fuchsia only.
I wouldn't bank much on Amazon. They just need an OS to run their readily disposable devices. I don't see them putting too much effort into this.
Google is going the hold the hand of manufacturers and ease them into it.
At least if Google had any sense this is how it would be done.
I think that's exactly what this is; it functions as insurance of sorts for the mobile world - such that they aren't totally locked out of a feasible platform (see tablets especially for both ) and also a "why not" for MS & Amazon both. It gives MS a starting point for an Android SDK + existing Amazon Android apps - and Amazon can bolster their offerings which currently are fairly barebones.
It could amount to little, of course. Even iOS apps on MacOS as a concept and practice has not remotely the luster ardent Apple acolytes predicted, certainly not yet even 7 months in.
Fuchsia is a kernel, not operating system. Google intends to swap Linux under Android to Fuchsia. One reason is the bad track record of Linux supporting device drivers.
> Its a new way of writing "native"-adjacent multiplatform applications; the OS doesn't matter anymore.
If only someone had thought about that before: a language targeting a bytecode interpreter and an ecosystem of library sitting on top of the operating system in order to be able to run programs on any operating system. In a way we could call it a virtual machine as it makes the OS insignificant. Written like this it sounds like 1994 tech. A shame we had to wait so long...
It's a great idea, but it will only work if it comes with a UI library that doesn't suck and a software distribution mechanism that doesn't suck. No-one wants to install "an app to run an app", so you need to distribute these applications as either native executables or something equally convenient, and it needs to be completely trivial for application developers to do that or they won't bother. That's the reason Electron is winning at the moment.
Byte Code and VMs are are older than just 90's tech but okay. I still honestly prefer native code, but it does not work well for non-open source software unless the developer also compiles for other systems. Also windows is really the only major non-*nix OS these days. Although apples GUI software stack is still a pain port for when porting.
There are people who complain about how the industry is moving in cycles and how what's old is new again and how functional languages did that back in 1922. These people don't change the world; they just complain about how other people are changing it.
Huh? I don't see how what I was saying was complaining? Sure things sometimes happen in cycles, I did not even mention that, but it is not necessarily a bad thing. VMs, and byte codes are a tool, and have their place. However, they do have their limitations compared to natively compiled code.
Just because it is bytecode it doesn't mean it is interpreted.
> Unlike some other virtual-machine architectures in which the virtual instructions are interpreted at run time, TIMI instructions are never interpreted. They constitute an intermediate compile time step and are translated into the processor's instruction set as the final compilation step. The TIMI instructions are stored within the final program object, in addition to the executable machine instructions. This is how application objects compiled on one processor family (e.g., the original CISC AS/400 48-bit processors) could be moved to a new processor (e.g., PowerPC 64-bit) without re-compilation. An application saved from the older 48-bit platform can simply be restored onto the new 64-bit platform where the operating system discards the old machine instructions and re-translates the TIMI instructions into 64-bit instructions for the new processor.
I thought Samsung had their own OS[0] that they were using for watches/smart TVs, and also keeping in their back pocket as a hedge against Google's influence? Are they giving that up?
Tizen is used for Smart TVs, refrigerators, and cameras. Targeting devices that need to be "smart" but have a relatively low CPU budget and at best embedded GPUs.
The most recent phone that shipped with Tizen had a 480 x 800 pixel display.
I hope they try, and I suspect it would end up the same way that OS/2 ended up for IBM, i.e. failure.
Not that I love or hate any particular company; but I do believe in (real) competition and I think this would help foster that. (Strong enemy of my enemy vibes here though.)
Google replacing Android might end up like when Intel tried to replace x86. AMD came along with AMD64 and forced Intel back into making compatible chips. It might end up being an even brighter future for Android.
This is great. Finally a non hacky way to run mobile apps on a desktop. This is less about competing with Apple’s universal binaries, and more about increasing Windows’s versatility.
You can already run Linux on Windows. Now you can run Android. No need to mess around with Archon, Nox, Genymotion anymore. Got a weather app you like? An audiobook player? Done.
Hopefully this means more interoperability with Microsoft’s own Android apps, so buying a phone like the Surface Duo and using the Your Phone feature actually does something.
I used BlueStacks for a while, while IME was never hacky. That said, there was/is little motivation for me to run mobile apps on desktop.
This definitely lowers the barrier to entry, thought I have little faith in how Microsoft will present it. Been burned too many times by them on poor UX/DX (WSL, F#)
Not sure what that guy is talking about, but some people are frustrated that WSL2 is basically a linux VM, and F# has been little more than an experimental playground for .net features. I don't care about either project, but these are the complaints I hear the most.
Absolutely. Way less janky than Mac's implementation of running iOS apps. While you can use mobile apps on your Windows laptop using native touch controls, on your Mac laptop you have to use that weird trackpad-driven interface. Which would you prefer? https://cdn.arstechnica.net/wp-content/uploads/2020/11/Mac-m...
I believe what they are saying (hoping for?) is that since there are many Windows compatible laptops with touchscreens (unlike macbooks), Android app experience on them might be better.
Microsoft had unified their software architecture across various form factors.
So xbox, (phones?), tablets, laptops, desktops, servers ran the same Windows essentially with different shells.
Windows also supports multiple hardware architectures - we just need the external ecosystem to thrive as well. We see it in graphics with nvidia and amd but compute/cpu progress limped through most of 2012-2018?.
"Android apps will run natively on Windows 11 and will be downloadable from Amazon’s Appstore, via the new Windows Store that’s included in the operating system." - confusion intensifies
I understand it in this way: you will find all Android apps published in the Amazon store also inside the Windows Store. So there is no need for republishing all Android apps to the windows store.
They partnered with Amazon. Google probably wasn’t helpful in integrating the play store.
Is it just me or does anyone else think this is Microsoft's first step to create it's own Android fork eventually?
I have been thinking what's really keeping the "new" Microsoft outside the smartphone game?
Google creating a desktop OS market share is not really on the horizon. But if Microsoft takes the right steps it might venture out to smartphones again, and gain market share this time. The HN crowd may not be the best audience for unified experience that Apple seems to be heading toward but there is sure demand for it in the mainstream.
>> For ages now, every annual report on desktop operating system market share has had the same top two contenders: Microsoft's Windows in a commanding lead at number one and Apple's macOS in distant second place. But in 2020, Chrome OS became the second-most popular OS, and Apple fell to third.
You are right but I somehow do not see Chromebook as a desktop OS. Maybe I am wrong, but this is exactly what I mean by the convergence that is happening. MS, I feel, wants a lighter OS for masses. Chromebook is surely dominating this space.
They wouldn't have Play Services, which gives all the power of the ecosystem. Just having a good desktop back country doesn't help anything in the mobile space, as Windows Phone showed. It also won't go without experienced hardware partners, and Samsung is already in Google's pocket, the other top dogs being Chinese, who don't look for fitting in the western markets anymore.
Not exactly. Play services/GCM is the push notification system on Android. Even on my completely degoogled phone I have to use microG to support push notifications from google's servers because every app developer has hardcoded their app to use GCM. It doesn't have to be that way. An alternate push notification service with a client alternative could be made available. Developers and users could start using it. Ideally there would be a standardized protocol, and a system setting so that the user can set their preferred push notification provider. Apps would use the system provided endpoint for push notifications and we would get a little control back. I sure wish I could self host push notifications.
Amazon Appstore (used for Microsoft's Android integration in Windows 11) uses Amazon Device Messgaing (ADM) instead of Google's Firebase Cloud Messgaing (FCM) for push notifications. A FCM receiver is built into Google Play Services to enable push notifications for Play Protect certified Android devices, but ADM is a viable alternative for Amazon and Microsoft as long as developers tailor and submit apps to the Amazon Appstore.
But why? I can think of exactly 0 Android apps I would like to run on my Windows desktop (and I've been an Android user since the original Samsung Galaxy S). Is this really something people crave to do?
Well for one the youtube app has access to secret forbidden content that the website doesn't. And the podcast app I paid for has a free phone version and a subscription non-phone version. For both of these, when I'm at my desktop, I want to use them on my desktop.
maybe ... they want to stop the javascript-based desktop app craze. E.g. their android skype mobile does not look much different from their skype desktop now.
Great, so now we can run React Native apps on Android on Windows. Apparently Microsoft heard we liked runtimes, so they put a runtime in our runtime so we can virtualize while we virtualize.
microsoft is more invested in the javascipt desktop app craze than almost anyone. they have github, visual studio code, and teams all running on javascript, plus the office 365 apps, which are eventually looking like they'll replace the old versions.
I am running and using 5 iOS on my M1 Macbook and they are useful to me. I wished we could continue sideloading iOS apps, but unfortunately Apple blocked that. And it sucks that devs can block installation of iOS apps on the Mac, although it is technically possible. This is artificial limitation purely for commercial reasons. Bad.
Apps are becoming bigger and bigger. Some will do loads of processing that only could be done on desktop before
The main reason to want these apps on windows are mechanical keyboards, mice, and file processing (think loading files from your pc). In my experience, 5% of all users want this (relevant) and quite badly, in fact
Instagram is intentionally annoying to use on browsers. Business users who have all their media in a folder and share an account between staff might welcome this. Post schedulers exist but are unreliable and annoying for adhoc posts.
I have multiple monitors and it's easier and more convenient to throw up an app on my screen and control with my mouse and keyboard than to pick up my phone, unlock it, and use that screen.
OTOH, now that I can sell my Android apps on the Microsoft store, why would I even bother to make a Windows-specific port?
Blackberry tried it with Blackberry 10 and failed. IBM failed the same way with OS/2. If you make your OS compatible with a foreign platform, there is less incentive to write original software for it and, therefore, there is less reason to get your platform instead of the one you are compatible with.
As a user though, why would I get an operating system / device that can only run Android software when I can get a device that can run both Android and Windows software?
And as an Android dev, I now have an incentive to optimize for Microsoft device form factors, which is a lot easier to do and maintain than making a whole port
And I don't see that there are too many developers who are now writing Windows desktop apps who will suddenly decide to rewrite for Android. Cos what apps are native? Stuff like CAD software, Unity, Photoshop, etc - stuff that has heavy complex UIs and wouldn't work well if at all in most Android contexts
> when I can get a device that can run both Android and Windows software?
That's the point. Over time, the volume of Windows-specific software should decrease because when you write for Android, you effectively target both platforms.
> who will suddenly decide to rewrite for Android.
That will be the case for a while, until there are Android devices with capabilities similar to a Windows computer. Apple neatly solved that with the M1-based iPads, as they are effectively more powerful than most Windows devices.
I agree with the sentiment. The only thing I can think of are certain mobile only banking apps. Maybe an SMS messaging app would be useful? Slim pickings from my quick scan of my phone.
There are platforms that debut on phones first and either are limited to phones or launch way later on web. WhatsApp for example was a phone only thing for such a long time.
Maybe Google licensed them some of the stack in return for telemetry on desktop users as well. Non-Chrome usage of desktops is a space Google can't get much data from and one they'd really want to access.
I can see that, especially since the Android emulators have been historically terrible (never tried the Intel one though, which maybe had some of this tech?).
But this was highlighted in the video clearly targeted at consumers with great fanfare, so I don't know...
This has been possible on ChromeOS (i.e. Chromebooks) for a while now and the experience is subpar. Most apps are not designed for desktop and the UX just feels unrefined. This could be fixed, of course, but on the app creators' side.
However, weirdly enough, VPN Android apps work just fine at a system level on Chromebooks. Go figure...
Microsoft really wants to convince you that your phone and your PC are the same thing. But they've failed in the execution of this idea several times now.
The fact that this partnership is with the Amazon app store, not the Google Play store, is a strong hint of how serious they are about this, and how this latest iteration will work out.
They had to partner with Amazon or no one. Amazon already has an android marketplace, and there's no way Google, who has a "competing" OS, is going to facilitate users using apps on windows. Google especially isn't going to combine the play store with the microsoft store and let MS call it the microsoft store.
A lot of web apps are not as good as their native counterparts. And maybe MS is planning an act 2 with foldable phone/tablet hybrids, after the failed Windows Phone.
There’s been a few attempts at containerised android apps on Linux too - Anbox and some others. Looks like that one runs on the Pine phone now too. Makes more sense for touch/smaller form factor, not so much for desktop (except maybe for some popular mobile only apps like TikTok)
Personally I have seen streams of people playing mobile games with gatcha-style monetization using their computers, and feed the game window into OBS. I don't think many of those games have PC counterparts. It sounds more convenient than having to set up an external capture card.
So Microsoft has its own App Store, then within that App Store there exists the Amazon App Store. Apps on this third layer will then be executable or sideloadable in Windows 11?
More like, "There is one Microsoft App Store, but apps on Amazon's Android App Store will also appear in Microsoft's App Store so you won't as a developer have to publish your Android app two places for them to show up in two places."
I would bet, for better or for worse, these Amazon Android apps will share metadata as well, so you'll see the same "Star" rating in both the Microsoft App Store and the Amazon Android App Store, but that's speculation on my part.
I have a few older friends that struggle with tech, but have learned their phone apps well. For them, this could be a benefit to not have to learn the differences between the app and website.
The security implications of this are interesting. There are some apps, namely Snapchat and Instagram, that guarantee privacy by taking advantage of the phone APIs that inform the app about screenshots. You can in theory work around those today with rooted/jailbroken phones, but those are a tiny part of the ecosystem.
But if everyone can run Snapchat on Windows, that kinda changes the whole game, unless they support the same APIs. But even then, it seems like it would be trivial to block that API.
How is Windows currently guaranteeing safety of DRM'ed media content? I seem to recall that you cannot play back some types of content on Windows for example if kernel debugging is enabled. Maybe they aren't that far from being able to guarantee that pixels aren't being grabbed for apps that do not want to have their pixels grabbed?
This seems backwards to me. Sure, apps should be at the mercy of they system when they want to use system-level features (interacting with other apps, accessing mic/camera, etc). But why should an application get to dictate which system features a user can invoke (taking a screenshot)?
> why should [applications] get to dictate which system features a user can invoke?
They shouldn't, but they do it anyway because virtually no users know how to "cheat", and most don't even know that they can cheat. The justification is that taking a screenshot violates your or someone else's privacy or security. In the case of security, they assume you're too dumb to know better.
I just went through my phone and there isn't a single Android app I'd actually want to use on my PC. Most of my apps are just hobbled versions of websites anyway, so I just use the fully functional browser with a full sized keyboard and nice big monitor and use the websites when I'm on the PC, and for that all I need is a single browser and the OS doesn't really matter.
I'm super excited to try the Android Apple Music app on Windows! We've been stuck with the bloated, slow iTunes desktop app for so long now. I was hoping they'd announce an update for it along with lossless and spatial audio, but there's been nothing so far.
BlueStacks claims to have more than 500 million users, I know a few friends who use it to play mobile only games on their PC for example. If android emulation was so useless on Windows, it wouldn't be so popular
I think the majority of mobile apps are very coupled to the mobile ecosystem. Or they exist to coverup the poor mobile web experience. I can use social media and messaging from any desktop web browser already. Anything geared around mobility or photography won't be very useful on a desktop. And at least a few apps just have "mobile only" as their edgy marketing strategy.
I get why this is potentially useful but I can't think a single app I'd actually use this way.
A big part of the reason Windows Phone failed was a lack of a good app ecosystem. Maybe they’re working their way toward a new Windows Phone that is compatible with Android apps?
Microsoft had an Android compat suite and an iOS compat suite in some of the Windows Mobile 10 betas.
They decided not to ship either one, although I don't think I ever saw an official reason.
The app ecosystem was a small part of the failure of Windows Mobile, IMHO. A larger issue was that they abandoned the low end in WM10, and that's where they were doing well in WP7 and 8. That each major version of the OS also had a new app framework was a lot of work for app developers, too. And blocking 3rd party browsers (mostly) and then making WM10 use Edge which was somehow worse than Mobile IE, when a browser is key on a platform without a lot of native apps didn't help.
The Amazon Appstore is awful, and due to issues between them and Google it is likely that you won't be able to install any Google Play Apps, like YouTube or Gmail. There are so many apps that pretend to actually be the official apps too and Amazon seems to not really flag anything from what I can tell.
I really hope there will still be a way to sideload the Google Play Store. It is one of the first things I do on Amazon devices.
Amazon's App Store and Google Play Store are distinct stores. Purchases do not carry over between them because they are competitors (in the same sense, you can't return an item to Walmart that you purchased at Target, even if they both sell it). You can install the Play Store on your Amazon devices, which allows you to use your Play purchases on the device (without jumping through too many hoops, like getting the apk and sideloading it).
This sounds like it's integrating with Amazon's app store directly so unless there's some way of sideloading Android apps using the underlying bridge to run them, Play Store purchases would not be available on Windows.
I figure the reason Amazon and Microsoft a ganging up in this way is precisely to address this issue: They want vendors to support a more portable mechanism for purchases that isn't tied to the Google silo.
Oh! What a neat idea, one which had never occurred to me. It sure would be awesome if EU or USA antitrust bodies legislated to force vendors to support a portable mechanism for purchases. It'd be nice if Google voluntarily enabled this, it'd give them a unique selling point over Apple and it would kick-start a (vibrant?) 3rd-party store ecosystem.
edit: the more i think about it the more it makes sense – multiple hardware vendors of the handsets themselves, then multiple software vendors of the the apps themselves. Would surely spur competitiveness and innovation when it comes to app pricing/bundling/sales/…
Unless something has changed recently that I'm unaware of, that definitely isn't currently possibly on Android itself. I assume it won't be possible using the Windows-version of the Amazon AppStore either. But maybe this will cause the devs to start pushing to make that a thing.
Absolutely not -- the Amazon app store and the Google Play store are completely different entities. The fact that Microsoft partnered with Amazon instead of Google for app store integration is a strong indication of how serious they are about this whole thing.
This is great. It heads off ChromeOS and makes the Surface hybrids even more attractive than they already are, which is no mean feat. Once this is out the Surface Books will cover basically all use cases at least decently. It'll be great to have cross op with their new foldable Android phones, too. Those machines are an absolute joy
Microsoft really killing it since Nadella took over
I mean, we can easily do this today and nobody does. Maybe there is a reason for that? Like apps that simply are not made for such large screens? Or the far majority of apps I would have interest on my computer expect a integrated SIM card or other mobile specific hardware.
On the other hand metro does not feel right on a big screen anyway, maybe it fits well?
Actually, in some cases mobile apps are higher quality than desktop versions. Mainly because the standard for mobile is to make native apps for the platform, while on desktop everything is Electron
I wonder how they'll manage the Play Services dependency, or whether apps that need SafetyNet checks would work. My guess is they won't, and they don't.
The whole problem is that Anbox is distributed as Snaps which is disliked by folks from many non Ubuntu-like Linux distributions. It would be interesting if there was a docker image with Anbox pre-installed that allowed playing with Android apps with zero configuration and setup.
I actively do not want this to become normalized. Things are bad enough as they currently stand, without further enabling appification and the degeneration of standards.
What degeneration of standards lmao. Desktop is the most degenerate of all platforms with their Electron cancer. At least on mobile it's mostly native.
I don't think they added a complete emulation of arm64, so it probably only runs apps with support for x86 (I have no idea of how many apps dont have support, but they exist) like BlueStack and most of emulators - So apple still has the advantage of using the same architecture for everything and running the apps natively.
how can windows run android apps but linux which is base of android itself cannot do that ?
what happened to arm and x86 differences? if rosetta stone thing is being done, why can't linux do that even natively on arm?
Android still uses bytecode for a lot of apps. Unless you're using Android NDK, which does have native code and requires different releases for different processors, ARM and x86 isn't really relevant.
Intel even made an attempt into the smartphone CPU market with the Asus ZenFone 4 back in 2014 with an Intel Atom x86 processor running Android. Modern Pixelbooks (and other x86 Chromebooks) run Android apps fine too, and those are technically Linux, so therefore it's already been done. Anbox also seems to do it fine in a container. Never tried that though.
But this running inside Windows.
Putting native code aside, it this just another emulator?
If it can out-perform all the other emulators is it likely to make them redundant ?
anbox is fine but the friction is just too great. last i tried was like year or two ago. it just ran stock apps. thats it.
my question was, why cant we use manjaro or ubuntu, double click on an apk and run it like an appimage? i am asking from the POV of an end user. I dont understand bytecode or ndk. if windows 11 can freely run an android app like it was a .exe, why cant my linux machine do that? anbox aside.
Want to highlight one paragraph from that description: "Intel Bridge Technology is run-time post compiler that can be integrated into Android-in-Container to enable certain Android apps – those not written in Java or compiled to run natively on Intel-based devices - to run on those devices."
How many Android apps out there are not written in Java? I'm guessing Kotlin isn't supported either. For that matter how many apps are targeting Android devices with Intel CPUs anymore?
I was expecting a full VM / emulator, but this doesn't sound like that.