Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I disagree. I would even say that it is as least as easy to support most Android-based devices than it is to support most Hardware running Windows.

In both platforms you run into very little issues for most apps, and you need to add support for lot's of different configurations if you write on the system level (Game developers can tell you a tale or two about this).



sort by: page size:

IIRC the thing about supporting Android is that with game engines, that typically means working with the NDK which as far as I can tell is a bit of a bear to deal with relative to desktop platforms.

You are talking about a different issue (the OS having to support different hardware platforms).

I was talking about developers claiming fragmentation makes it hard to write programs for the OS running on different hardware platforms. My point is that the same level of complexity is involved in writing an Android app running on multiple Android versions and mobiles, and in writing a Windows app running on different Windows versions and PCs. And in both cases, it can be done relatively easily.


Do you really expect your app to run on all Windows machines flawlessly?

By and large, yes, people expect that and developers largely achieve that. But of course Windows is a much more mature platform than Android.


Hardware support matters to end users in terms of portability of app data. If I use an app which is not ported to other platforms, I can't use my data in a new hardware, until the platform itself is ported.

If the data has an open format, then this problem is reduced, but many applications out there have a proprietary data format.


The root of the problem is that not everyone is on the same version of Android.

Alternatively, it seems the root of the problem is that all the different versions of Android don't have enough commonality for compatibility. I have apps which were originally written for Win95 and continue to work on Win10. Microsoft hasn't always made great decisions, particularly recently, but seeing a single small binary run unchanged over 20+ years of platform differences is something that IMHO other companies can learn much from.

(I know Android devices, despite mostly being ARM, cover a wider range of architectures... but isn't that what basing everything on Java was supposed to solve?)


In different areas, though. Windows also supports some very old hardware and the FOSS community is also out of luck when phone chip makers stop releasing blobs/kernels.

That’s only true for apps that are compiled and run on a PC. Most general purpose computers in the world run ARM/Android.

agreed, as a developer i don't need an android device to test, just open a simulator and most things will work. on the other hand you cant even compile for ios with a linux/windows pc.

They are closer to Linux APIs than Windows ever will.

Android even more so, assuming those that rely only on AGK/NDK.


Yes, the concerns raised about resigning apps and sideloading capability is not something the average Windows user will care about.

Android apps are also inferior to Windows apps, so the real question is: Who is going to use Android apps on Windows.

Android app developers seem to be the target group.


I think the main problem there is that they render graphics on the cpu. Also, an android desktop machine would most likely use an ARM architecture, making the point moot.

The only reason to run Android apps on Windows is because there aren't native Windows versions of these applications.

Another advantage the Android platform has specifically is that its applications mostly consist of bytecode, limiting the impact phasing out 32 bit instructions has on the platform. Most high performance chips are in Android devices like phones and tablets where native libraries are more the exception than the rule.

Desktop relies on a lot of legacy support because even today developers make (unjust) assumptions that a certain system quirk will work for the next few years. There's no good reason to drop x86 support and there's good reason to keep it. The PC world can't afford to pull an Apple because there's less of a fan cult around most PC products that helps shift the blame on developers when their favourite games stop working.


Think you missed the point. Now you can build your app for win8, something you intill now was only theoretical possible. What you describes is how you setup an android environment on Windows...

I think that the point of this comment is that that's mostly incorrect. There are support libraries which basically mean that any device can run at any API level. This is fact, it has been for a while. Suck it up.

Wouldn't the existence of semi-functional Android app compatibility just mean that developers abandon native apps entirely? It reminds me of a similar dilemma with OS/2. It could run Windows apps, so people stopped writing native ones.

It may not be so bad because most of Android apps are built on Java which isolates a lot of what OS does. For other native apps, if Google builds a POSIX compliant OS, it should be fairly easy to port/run.

same goes for other platforms too, you know.

The only advantage for Android is that you can theoretically also just distribute via sideloading


Does it also make Android development easier on Windows? i.e. can I build an Android app and open it via the subsystem, without having to run an emulator?
next

Legal | privacy