Neither Microsoft, Nokia, nor anyone else should fork Android. It’s unforkable.(arstechnica.com)
arstechnica.com
Neither Microsoft, Nokia, nor anyone else should fork Android. It’s unforkable.
http://arstechnica.com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/
215 comments
Google's AOSP is FOSS, Android you get on a typical phone isn't. You got bunch of proprietary binaries, kernel source code (usually, even without a toolchain to build it), and, well, that's about it.
Fuck open source, I don't give shit about Samsung/Sony/Motorola developers and how they are happy with Apache license they took AOSP under. I - the user - want free software on my phone and I mean the software that respects my freedoms. In this regard, average Android phone isn't free by any standards.
But, yeah, right, AOSP is open. Like this fact is of any use to an average tech-savvy consumer who's not skilled at reverse engineering.
Fuck open source, I don't give shit about Samsung/Sony/Motorola developers and how they are happy with Apache license they took AOSP under. I - the user - want free software on my phone and I mean the software that respects my freedoms. In this regard, average Android phone isn't free by any standards.
But, yeah, right, AOSP is open. Like this fact is of any use to an average tech-savvy consumer who's not skilled at reverse engineering.
It's really weird that people talk about phones like general purpose computers that they should be in control of...I'm just pointing out that it has NEVER been the case. I'm not even sure what it would take to get to where it could be.
With PC's there was some FCC oversight, being a device without a transmitter meant that there wasn't a whole lot though. With cell phones they are so heavily regulated...and the carrier is such an integral part of the equation. It seems like you might get more of what you want with a wifi handset or device. The carriers have no vested interest in making a handset like you describe and their monopoly status makes market pressures almost non-existent forces for change.
Just rambling...
With PC's there was some FCC oversight, being a device without a transmitter meant that there wasn't a whole lot though. With cell phones they are so heavily regulated...and the carrier is such an integral part of the equation. It seems like you might get more of what you want with a wifi handset or device. The carriers have no vested interest in making a handset like you describe and their monopoly status makes market pressures almost non-existent forces for change.
Just rambling...
It's not open source because the average consumer wouldn't know what to do with the source code? what the hell kind of argument is that? Open source isn't about end-users, it's about developer freedom. And developers are free to use android to build things. that's what open source is.
Just because you've chosen to create your own ill-informed definition of what open means, doesn't make android any less open.
Just because you've chosen to create your own ill-informed definition of what open means, doesn't make android any less open.
It all boils down to what you call "Android."
AOSP is open source, I've already said that. It doesn't care about my freedoms (so I don't care about its openness), but it's "open" as in OSI definition. That's true and I've never argued about that.
However, typical Android you get on smartphone (that's called "Android", too) is neither open nor free - it's usually completely proprietary bootloader, firmware and userspace, you won't have any source code for anything except for GPLed parts (i.e. Linux kernel). It just happens that those proprietary binaries were mostly built from unmodified AOSP code (but you can't really tell if code's modified or not), but this doesn't make them open.
AOSP is open source, I've already said that. It doesn't care about my freedoms (so I don't care about its openness), but it's "open" as in OSI definition. That's true and I've never argued about that.
However, typical Android you get on smartphone (that's called "Android", too) is neither open nor free - it's usually completely proprietary bootloader, firmware and userspace, you won't have any source code for anything except for GPLed parts (i.e. Linux kernel). It just happens that those proprietary binaries were mostly built from unmodified AOSP code (but you can't really tell if code's modified or not), but this doesn't make them open.
I'm surprised no-one's mentioned Replicant, which "aims to replace all proprietary Android components with their free software counterparts"
http://en.wikipedia.org/wiki/Replicant_(operating_system)
http://en.wikipedia.org/wiki/Replicant_(operating_system)
That's mostly about binary drivers for hardware though, which remains a struggle for desktop Linux too.
So you're upset that they call it "Android" ?
You know you can change what's installed on your handset? Cyanogenmod supports a ton of phones... maybe next time you buy a handset, check they support it.
You know you can change what's installed on your handset? Cyanogenmod supports a ton of phones... maybe next time you buy a handset, check they support it.
> You know you can change what's installed on your handset?
Ah, thanks for suggestions. Actually, I've had to buy a smartphone recently, and tried exactly what you suggested. Unfortunately it seems that Cyanogenmod has almost non-existent support for dual-SIM phones (at least nothing for what was available, and I was in a bit of hurry), and due to personal circumstances I needed this kind of hardware.
Ah, thanks for suggestions. Actually, I've had to buy a smartphone recently, and tried exactly what you suggested. Unfortunately it seems that Cyanogenmod has almost non-existent support for dual-SIM phones (at least nothing for what was available, and I was in a bit of hurry), and due to personal circumstances I needed this kind of hardware.
Then maybe it's better to discuss whether Android, as ultimately delivered to end-users, is free software.
http://www.gnu.org/philosophy/free-sw.html
http://www.gnu.org/philosophy/free-software-even-more-import...
Regardless of whether most users know what to do with the source code, are they free to ask or hire a developer of their choice to study and modify it on their behalf? drdaeman's point, which seems inarguable to me, is that with most Android devices, the answer is no, because Sony/Samsung/Motorola are free to use AOSP code under the Apache license, but they don't pass that freedom on to the user.
http://www.gnu.org/philosophy/free-sw.html
http://www.gnu.org/philosophy/free-software-even-more-import...
Regardless of whether most users know what to do with the source code, are they free to ask or hire a developer of their choice to study and modify it on their behalf? drdaeman's point, which seems inarguable to me, is that with most Android devices, the answer is no, because Sony/Samsung/Motorola are free to use AOSP code under the Apache license, but they don't pass that freedom on to the user.
I believe that's called "moving the goalposts". Android is free. that's what the original discussion was. No, most of the time products based on android as delivered to customers are not free software. But that doesn't mean android isn't free.
Well it also implies that Android isn't popular with consumers so isn't much worth talking about, as consumers.
As usual, RMS had this sussed out years before everyone else realised what was going on http://www.theguardian.com/technology/2011/sep/19/android-fr...
Relevant to this discussion is that Google's nefarious plans (more people using the internet) would have been met even with a fully free software stack. They had to expend more effort building an Apache codebase to appease their partners, who wanted to have their own (minor) proprietary forks.
This actually makes Android more attractive to Microsoft and generally increases the chance of a divergent, proprietary fork, which I believe Kindle already is.
This actually makes Android more attractive to Microsoft and generally increases the chance of a divergent, proprietary fork, which I believe Kindle already is.
Not just that really, I think his point is more so that AOSP will not build and run for 99% of phones out there (i.e. non-Nexus phones). There's a lot of reverse engineering that goes on from people like CyanogenMod to make it work on other devices. Manufacturers release kernel source, as they must, but they rarely release other modifications they make for their own devices to even boot. There's a lot of stupidity in the Android "hacker" community (i.e. XDA) where people go around saying "X manufacturer doesn't release their sources, I'm boycotting X" when in reality, except for the Chinese OEMs they do release the source that they're required to release, it's just that 90% of the time that source is nowhere near enough to produce a build that you can run on your phone.
Open source is not for end users you are right. Fre software is, its where I as user would expect to have root by default on my own phone. Its a huge difference.
Free software assumes that all end users might want to modify it, regardless of those users' current skill set. I may not be capable of modifying kernel source code today, but who knows what the future might bring.
Even if end users can't modify it themselves, they can hire developers to do it. This effectively creates a market for software customization/personalization, whereas closed-source software is more akin to a monopoly (whoever holds the source code, holds the monopoly to fixing bugs/adding features).
> Open source isn't about end-users, it's about developer freedom.
That is why FSF keeps criticizing "Open Source". This nonsense is awful. Software freedom is extremely important to end-users. They might like to do something as simple as protect their privacy and turn off surveillance or uninstall bloatware! If Open Source isn't about those things at all (even though they do NOT require programming skills!), then we really need to keep focusing on software freedom for real and not your insulting interpretation of "Open Source"
That is why FSF keeps criticizing "Open Source". This nonsense is awful. Software freedom is extremely important to end-users. They might like to do something as simple as protect their privacy and turn off surveillance or uninstall bloatware! If Open Source isn't about those things at all (even though they do NOT require programming skills!), then we really need to keep focusing on software freedom for real and not your insulting interpretation of "Open Source"
> That is open source in my book.
Have you actually built and installed AOSP on a device? If you have you might not completely agree with that statement above because without proprietary firmware and closed sourced device drivers those devices often become unusable.
That is completely ignored by your post. Is it on purpose?
JBQ (their AOSP "liason" to the community even quit over that issue) -- people complaining that open isn't really that open.
https://plus.google.com/+JeanBaptisteQueru/posts/9HHRURorE7g
So it is not just me raving about.
I understand Google though. They don't design all those sensors and drivers and all the hardware but have other manufacturers make the devices who buy components from others and so on. So they don't have a choice. But regardless of blame assignment here, I can't honestly say the system is completely open.
Now if you are Amazon or Microsoft, ok, you can find a hardware builder with its own custom drivers just for your device, then forking could work out. But for enthusiasts and experimenting you need to download the proprietary drivers to get a usable device, simple as that.
Have you actually built and installed AOSP on a device? If you have you might not completely agree with that statement above because without proprietary firmware and closed sourced device drivers those devices often become unusable.
That is completely ignored by your post. Is it on purpose?
JBQ (their AOSP "liason" to the community even quit over that issue) -- people complaining that open isn't really that open.
https://plus.google.com/+JeanBaptisteQueru/posts/9HHRURorE7g
So it is not just me raving about.
I understand Google though. They don't design all those sensors and drivers and all the hardware but have other manufacturers make the devices who buy components from others and so on. So they don't have a choice. But regardless of blame assignment here, I can't honestly say the system is completely open.
Now if you are Amazon or Microsoft, ok, you can find a hardware builder with its own custom drivers just for your device, then forking could work out. But for enthusiasts and experimenting you need to download the proprietary drivers to get a usable device, simple as that.
So write your own open source reverse engineered drivers or find a manufacturer that gives you docs for their sensors. It's what the Linux crowd has done for a decade now. That's what hacking and tinkering are all about. They are doing free and open Adreno drivers for example. Also Tegra. Saying Android is not open source because it doesn't come with open drivers for all current and future hardware is just plain impractical. It just means you want everything in your plate. It doesn't mean Android isn't open.
Edit: Noticed people might be taking offense to my strong wording.
Edit: Noticed people might be taking offense to my strong wording.
Quite, but by the time you finish that the next generation is out and everybody has moved on.
The same thing happened with the HTC devices and Linux ports, it took years to get a port working and by the time it did everybody had a newer Android device (or whatever). A few people still use the HD2 and I still see questions on our (HTCLinux) Facebook page from people, but, for the most part, even XDA has moved on.
The 'current and future hardware' part is what Linux is really about, it's an abstraction layer over the specific hardware so that the user experience can be implemented once and used on many devices. Unfortunately, the lack of support for current 3D hardware means that the abstraction is incomplete. The development processes of the OEMs also break this abstraction, with everything build around one version of the kernel, one version of the phone HAL, one version of the camera driver and module, and the rest. Android, as delivered by OEMs, is not designed to adapt to other hardware. It's open in the sense that the core code is available, but not in the sense that the higher layer can be used as is on a new device.
Support for future hardware is not neccesary, but a profile that allows that hardware to be used once drivers are provided is desirable. This requires a strong abstraction between the Android userland and Linux kernel, GLES with standard DRI/DRM interfaces, UVC for the camera module (or an SoC-specific open specification much like ASoC is for audio), standard IOCTLs and sockets for network devices (wifi could use net80211 for instance), upstream Bluetooth stack including WiPHY, HE, and LE support, with working A2DP audio routing, input devices with valid metadata in the driver so they can be probed, supported flash filesystem, and probably some others.
Then Google takes this and builds a set of tests that verify that these requirements have been met, and states that the next 3 versions of Android will use this base.
They also provide an ABI guideline (so version) for the phone interface, the audio playback, sensors, and other aspects provided by libhardware. They make the same commitment: the next 3 versions will require this so version of libhardware.
The OEMs get this set of guidelines and build a device to meet them, passing the tests provided by Google.
Then Google releases an OTA version of Android that works on top of this base. Then they release another, and another.
As features require it, they amend the guidelines, adding NFC for instance. Not all devices support NFC and on those that don't, the functionality is not exposed by Android.
The same thing happened with the HTC devices and Linux ports, it took years to get a port working and by the time it did everybody had a newer Android device (or whatever). A few people still use the HD2 and I still see questions on our (HTCLinux) Facebook page from people, but, for the most part, even XDA has moved on.
The 'current and future hardware' part is what Linux is really about, it's an abstraction layer over the specific hardware so that the user experience can be implemented once and used on many devices. Unfortunately, the lack of support for current 3D hardware means that the abstraction is incomplete. The development processes of the OEMs also break this abstraction, with everything build around one version of the kernel, one version of the phone HAL, one version of the camera driver and module, and the rest. Android, as delivered by OEMs, is not designed to adapt to other hardware. It's open in the sense that the core code is available, but not in the sense that the higher layer can be used as is on a new device.
Support for future hardware is not neccesary, but a profile that allows that hardware to be used once drivers are provided is desirable. This requires a strong abstraction between the Android userland and Linux kernel, GLES with standard DRI/DRM interfaces, UVC for the camera module (or an SoC-specific open specification much like ASoC is for audio), standard IOCTLs and sockets for network devices (wifi could use net80211 for instance), upstream Bluetooth stack including WiPHY, HE, and LE support, with working A2DP audio routing, input devices with valid metadata in the driver so they can be probed, supported flash filesystem, and probably some others.
Then Google takes this and builds a set of tests that verify that these requirements have been met, and states that the next 3 versions of Android will use this base.
They also provide an ABI guideline (so version) for the phone interface, the audio playback, sensors, and other aspects provided by libhardware. They make the same commitment: the next 3 versions will require this so version of libhardware.
The OEMs get this set of guidelines and build a device to meet them, passing the tests provided by Google.
Then Google releases an OTA version of Android that works on top of this base. Then they release another, and another.
As features require it, they amend the guidelines, adding NFC for instance. Not all devices support NFC and on those that don't, the functionality is not exposed by Android.
>Android, as delivered by OEMs, is not designed to adapt to other hardware. It's open in the sense that the core code is available, but not in the sense that the higher layer can be used as is on a new device.
Don't you think that's more due to the way ARM / mobile hardware scene is than due to Android? There isn't something like a BIOS or ACPI type of standardization to make that kind of thing happen. Also the pace of obsoletion is way faster in the mobile space than it ever was in the PC space.
Don't you think that's more due to the way ARM / mobile hardware scene is than due to Android? There isn't something like a BIOS or ACPI type of standardization to make that kind of thing happen. Also the pace of obsoletion is way faster in the mobile space than it ever was in the PC space.
Initially it was, but Android/Google have become the establishment. And ARM-based devices are becoming our general-purpose computing devices. Having an option for running the software we choose is the question of whether we have open computing device in the future.
There actually is a solution at the hardware/firmware/driver level now, the ARM Linux community has adopted DeviceTree, actually a varient called FDT, and drivers have migrated from the one-off platform buses to FDT. Even vendors like Qualcomm are embracing it and the time to upstream is falling.
As far as bootloaders, there are a number of open options. also don't personally see anything wrong with EFI on ARM, as long as there is a way for the end user to choose what signatures are accepted when booting software. A standard for describing memory layouts independent of hardware is important, as that allows for the newer multi-SoC ARM Linux kernels along with DT for defining the hardware and what driver should bind to what hardware device.
There are standards that exist at this layer, as long as the OEMs and SoC makers adopt them.
The basic concepts of SoCs are not being obsoleted, and the basic set of devices that need to be present to boot a system are not really changing that much, specific buses are changing, better DMA mapping is supported on newer hardware, including IOMMUs, but the basic concepts are still pretty much the same.
My proposal takes place at a different layer though, and is more focused on the fragmentation problem of Android.
Essentially you have an ARM ABI standard which defines what registers a call into the Linux kernel uses, this used to be more complicated with multiple ARM ABIs. Now it's pretty simple and ARM binaries on Linux work across devices, across SoCs, across Android OEM vendors. This is not much better or worse than the same compatibility on x86/x64.
The issue lies in the "expanded ABI," the suite of drivers, libraries, daemons, configuration, RPC procedures, hardware specific IOCTLs, and other particulars of each OEM's hardware. A Samsung camera APK isn't going to work on a device with a different sensor, even though they are both coded to Android's camera APIs. They might handle zoom differently, or lighting. They might handle sending the uncompressed stream to the DSP differently, or drawing into the LCDC different for real-time previews. They might handle flash timing differently. But what would happen if this was a plugin for the standard Google or even AOSP camera instead? What if this was a defined API/ABI that CyanogenMod could use on that hardware, or Firefox Apps with embedded WebAPI camera media source and canvas? What about capturing from the command line with something like uvctool?
Numbers like 4.4 at 2% (from another story today) should scare Google. It should scare them when apps built for Chrome Mobile don't work on all Android devices. It should scare them when the improvements made to Google Now won't be usable by an overwhelming proportion of their users. It should scare them when others like Yahoo and Mozilla can come in and poach Android users stuck on an outdated version of Android and build alternatives economies on their own (Google's) partner's flagship devices. And they should respond by competing.
There actually is a solution at the hardware/firmware/driver level now, the ARM Linux community has adopted DeviceTree, actually a varient called FDT, and drivers have migrated from the one-off platform buses to FDT. Even vendors like Qualcomm are embracing it and the time to upstream is falling.
As far as bootloaders, there are a number of open options. also don't personally see anything wrong with EFI on ARM, as long as there is a way for the end user to choose what signatures are accepted when booting software. A standard for describing memory layouts independent of hardware is important, as that allows for the newer multi-SoC ARM Linux kernels along with DT for defining the hardware and what driver should bind to what hardware device.
There are standards that exist at this layer, as long as the OEMs and SoC makers adopt them.
The basic concepts of SoCs are not being obsoleted, and the basic set of devices that need to be present to boot a system are not really changing that much, specific buses are changing, better DMA mapping is supported on newer hardware, including IOMMUs, but the basic concepts are still pretty much the same.
My proposal takes place at a different layer though, and is more focused on the fragmentation problem of Android.
Essentially you have an ARM ABI standard which defines what registers a call into the Linux kernel uses, this used to be more complicated with multiple ARM ABIs. Now it's pretty simple and ARM binaries on Linux work across devices, across SoCs, across Android OEM vendors. This is not much better or worse than the same compatibility on x86/x64.
The issue lies in the "expanded ABI," the suite of drivers, libraries, daemons, configuration, RPC procedures, hardware specific IOCTLs, and other particulars of each OEM's hardware. A Samsung camera APK isn't going to work on a device with a different sensor, even though they are both coded to Android's camera APIs. They might handle zoom differently, or lighting. They might handle sending the uncompressed stream to the DSP differently, or drawing into the LCDC different for real-time previews. They might handle flash timing differently. But what would happen if this was a plugin for the standard Google or even AOSP camera instead? What if this was a defined API/ABI that CyanogenMod could use on that hardware, or Firefox Apps with embedded WebAPI camera media source and canvas? What about capturing from the command line with something like uvctool?
Numbers like 4.4 at 2% (from another story today) should scare Google. It should scare them when apps built for Chrome Mobile don't work on all Android devices. It should scare them when the improvements made to Google Now won't be usable by an overwhelming proportion of their users. It should scare them when others like Yahoo and Mozilla can come in and poach Android users stuck on an outdated version of Android and build alternatives economies on their own (Google's) partner's flagship devices. And they should respond by competing.
>Have you actually built and installed AOSP on a device?
Yes. I work with embedded Android at the driver and framework integration level. This is my every day.
I'm not really concerned that someone can't load AOSP on some cheap AT&T subsidised phone. Does that make the framework less free? No, that means they have non-free hardware.
Yes. I work with embedded Android at the driver and framework integration level. This is my every day.
I'm not really concerned that someone can't load AOSP on some cheap AT&T subsidised phone. Does that make the framework less free? No, that means they have non-free hardware.
I couldn't even load it on Nexus device without proprietary drivers. Some of which were not released for quite a bit. Those are not just Chinese knock-off those are Nexus devices.
> No, that means they have non-free hardware.
My Lenovo laptop is also non-free hardware, it works very well without closed source drivers.
> No, that means they have non-free hardware.
My Lenovo laptop is also non-free hardware, it works very well without closed source drivers.
Because people made it work. People can do that for AOSP, but they haven't yet. Go do it!
> Because people made it work.
Right, and they haven't made all these other Android devices work. So, "Android is open source" statement is only true with some major fine print attached to the bottom. That was my point and I was trying to clarify the misconception.
Right, and they haven't made all these other Android devices work. So, "Android is open source" statement is only true with some major fine print attached to the bottom. That was my point and I was trying to clarify the misconception.
People can also reverse engineer Windows and "make it work". That doesn't mean it's open.
Would that be the same Lenovo range that gets regularly recommended for use with Linux because, unlike many others, it works well with Linux? If so that rather undermines its relevance here.
Have you been able to get GLES 2.0 working on an AOSP device with manufacturer provided drivers? Do the modern rendering features like renderscript work? What about audio and video codecs (like h.264, etc. not the PCM codecs)? Do common downloadable games that depend on 3D features work? Are they playable?
AOSP is great to bring up on a framebuffer-based device, but that gets you as far as an Android 2.0 launcher.
Any idea if Chromium can be build for AOSP with similar features as Chrome on Android?
AOSP is great to bring up on a framebuffer-based device, but that gets you as far as an Android 2.0 launcher.
Any idea if Chromium can be build for AOSP with similar features as Chrome on Android?
I've reread my comment and am trying to see where I was critical of Android.
AOSP is open source, and it has parity with commercial distributions of Android in a number of areas.
I have been working with Android and Linux on Qualcomm MSM-based devices for a few years, navigating their portal at codeaurora.org, tearing into Android kernel commits and following the upstreaming process. The changes that Android makes to Linux are minor, and most of the them have been merged into the upstream kernel in some form.
The Linux framebuffer started out as a device wrapping the memory-mapped display memory of the Amiga and similar RISC devices, then it was ported to the Netwinder, which was an early embedded ARM computer in a screen. It has a minimal set of operations for accelerated graphics, it can do fast fills or clear the screen for instance. It does not support 3D graphics, it does not support most of the 2D primitives that X and the Android rendering libraries (such as surfaceflinger) require. Android had an extended protocol for using some of the features to enhance fast blits of of data from an offscreen buffer to the main display buffer. This was implemented using IOCTLs on top of the framebuffer, and by reusing some of the features in a different way.
This is sufficient to get you a basic Android launch screen, you won't get the 3D launcher screen, you won't get the enhanced gallery plugin, you won't get fast Google Maps/Earth rendering, and you won't be able to play 3D games. For that you need a 3D graphics driver. Most of these drivers are tightly controlled by the company that makes the chip, are closed source, and are not readily reverse engineered. Some projects have made progress, but it's been a slow process. LIMA is an implementation of the ARM Mali driver for instance. Recently, Nvidia submitted a patch to Nouveau for their Tegra device. This breaks with years of not cooporating with development of 3D drivers for their devices on Linux, and has the potential for a bright future of AOSP 3D graphics support on Tegra devices.
AOSP is open source, and it has parity with commercial distributions of Android in a number of areas.
I have been working with Android and Linux on Qualcomm MSM-based devices for a few years, navigating their portal at codeaurora.org, tearing into Android kernel commits and following the upstreaming process. The changes that Android makes to Linux are minor, and most of the them have been merged into the upstream kernel in some form.
The Linux framebuffer started out as a device wrapping the memory-mapped display memory of the Amiga and similar RISC devices, then it was ported to the Netwinder, which was an early embedded ARM computer in a screen. It has a minimal set of operations for accelerated graphics, it can do fast fills or clear the screen for instance. It does not support 3D graphics, it does not support most of the 2D primitives that X and the Android rendering libraries (such as surfaceflinger) require. Android had an extended protocol for using some of the features to enhance fast blits of of data from an offscreen buffer to the main display buffer. This was implemented using IOCTLs on top of the framebuffer, and by reusing some of the features in a different way.
This is sufficient to get you a basic Android launch screen, you won't get the 3D launcher screen, you won't get the enhanced gallery plugin, you won't get fast Google Maps/Earth rendering, and you won't be able to play 3D games. For that you need a 3D graphics driver. Most of these drivers are tightly controlled by the company that makes the chip, are closed source, and are not readily reverse engineered. Some projects have made progress, but it's been a slow process. LIMA is an implementation of the ARM Mali driver for instance. Recently, Nvidia submitted a patch to Nouveau for their Tegra device. This breaks with years of not cooporating with development of 3D drivers for their devices on Linux, and has the potential for a bright future of AOSP 3D graphics support on Tegra devices.
Oh sorry, I read it as a jab against Android for its reliance on non-free drivers and firmware. Sorry for assuming!
Ha, no problem. I was actually asking your experience with those things.
I am a little critical of people declaring Android great because it's open, while ignoring the limitations of AOSP. Unfortunately, this is a trend for or against many popular platforms where emotional responses replace reasoned consideration of the pros and cons of the products.
I've seen this a lot in discussions around Android, iOS, and Windows Phone. I prefer to inform and learn more about the platforms and use that discussion to shape my internal image of the state of the mobile industry. I care about the good features of Windows Phone. I care about the negatives of closed source drivers on Android, even as I'm aware of the limitations that Google's Android business had at the time that these decisions were made. I consider the iPhone, when it was released, to be very positive step forward and superior to pretty much every device a normal consumer would consider at the time. The willingness to seize control from the carriers, support apps from developers that couldn't afford the licensing fees and restrictions for BREW, and the limited number of phones that it supported, and revolutionize mobile OSs toward a modern graphics rendering, interaction, etc. was a huge boon to the industry. But I'm also willing to criticize the control Apple has over the choice of applications they distribute for competitive reasons. I want the ability to install any app I wish on my device. I want the ability to build applications for my device without joining a paid program, or being limited in who I can share my developed app with. I want to be able to choose the license my code is released under while still being able to distribute it in the most used venue.
I want a device with integrated services, but I want to choose which services I use.
I want full 3D support in open source so that anyone can go out there and build a new experience for their device from the ground up, and not be limited to the one that Android provides. FirefoxOS on every device, Ubuntu Mobile, Open WebOS, and plain old X.
I don't see the point of criticizing Android itself for lacking open 3D drivers, I use a Samsung Galaxy S4, Google services, Google Play, and the Chrome browser. (As well as Firefox for Disqus sites, for some reason.) But I don't see myself using AOSP as delivered.
I am a little critical of people declaring Android great because it's open, while ignoring the limitations of AOSP. Unfortunately, this is a trend for or against many popular platforms where emotional responses replace reasoned consideration of the pros and cons of the products.
I've seen this a lot in discussions around Android, iOS, and Windows Phone. I prefer to inform and learn more about the platforms and use that discussion to shape my internal image of the state of the mobile industry. I care about the good features of Windows Phone. I care about the negatives of closed source drivers on Android, even as I'm aware of the limitations that Google's Android business had at the time that these decisions were made. I consider the iPhone, when it was released, to be very positive step forward and superior to pretty much every device a normal consumer would consider at the time. The willingness to seize control from the carriers, support apps from developers that couldn't afford the licensing fees and restrictions for BREW, and the limited number of phones that it supported, and revolutionize mobile OSs toward a modern graphics rendering, interaction, etc. was a huge boon to the industry. But I'm also willing to criticize the control Apple has over the choice of applications they distribute for competitive reasons. I want the ability to install any app I wish on my device. I want the ability to build applications for my device without joining a paid program, or being limited in who I can share my developed app with. I want to be able to choose the license my code is released under while still being able to distribute it in the most used venue.
I want a device with integrated services, but I want to choose which services I use.
I want full 3D support in open source so that anyone can go out there and build a new experience for their device from the ground up, and not be limited to the one that Android provides. FirefoxOS on every device, Ubuntu Mobile, Open WebOS, and plain old X.
I don't see the point of criticizing Android itself for lacking open 3D drivers, I use a Samsung Galaxy S4, Google services, Google Play, and the Chrome browser. (As well as Firefox for Disqus sites, for some reason.) But I don't see myself using AOSP as delivered.
> I am a little critical of people declaring Android great because it's open
I am in the same boat (I made the original comment referring to the drivers). Now it is partly through my own ignorance. I assumed if I just followed the steps to built and install AOSP (plus some patches I was trying out), I would have gotten a functional Nexus 7, minus all the google apps of course. Well rotation sensor, and other wasn't working, GPU was slow, other stuff was crippled. The device was basically not usable very much.
Now yes, Android on a scale is a lot more open than say Apple products for kudos for them. But at the same time the fine print associated with AOSP is a little too much for the project to be proclaimed completely "open".
I am in the same boat (I made the original comment referring to the drivers). Now it is partly through my own ignorance. I assumed if I just followed the steps to built and install AOSP (plus some patches I was trying out), I would have gotten a functional Nexus 7, minus all the google apps of course. Well rotation sensor, and other wasn't working, GPU was slow, other stuff was crippled. The device was basically not usable very much.
Now yes, Android on a scale is a lot more open than say Apple products for kudos for them. But at the same time the fine print associated with AOSP is a little too much for the project to be proclaimed completely "open".
>Have you been able to get GLES 2.0 working on an AOSP device with manufacturer provided drivers?
No. This is a problem that extends far beyond Android and existed before it showed its face on the scene. Non-free graphics drivers are common on desktop Linux too.
No. This is a problem that extends far beyond Android and existed before it showed its face on the scene. Non-free graphics drivers are common on desktop Linux too.
>The "android isn't very open source" sentiment really bothers me and I see it a lot here. It is a complete and fully functional mobile OS under extremely permissive licensing. Pull it! Change it! Build it! Fork it! Whatever!
The fact that you could theoritically "fork it and change it" doesn't change the fact that Android, the thing that is actually shipped, is not open itself, in the sense that it's not a community project, where everybody's opinion has equal weight based on their work, community standing, etc.
Without an actual community behind it, like Gnome or KDE, or FreeBSD have, one cannot influence it much, one's vote doesn't count, and "fork it and change it" is not really feasible -- who'll be paying for that?
>The code is there in a series of open git repos and under Apache license. That is open source in my book.
Well, that's the least interesting part of being open source. The actual important attribute of being open source is being a community project (cathedral vs bazaar etc).
The fact that you could theoritically "fork it and change it" doesn't change the fact that Android, the thing that is actually shipped, is not open itself, in the sense that it's not a community project, where everybody's opinion has equal weight based on their work, community standing, etc.
Without an actual community behind it, like Gnome or KDE, or FreeBSD have, one cannot influence it much, one's vote doesn't count, and "fork it and change it" is not really feasible -- who'll be paying for that?
>The code is there in a series of open git repos and under Apache license. That is open source in my book.
Well, that's the least interesting part of being open source. The actual important attribute of being open source is being a community project (cathedral vs bazaar etc).
I think the issue is that all of those Google services are really what makes Android Android. An Android phone lacking integration with Gmail, Google Calendar, etc, without something else to make it compelling (like the Kindle Fire), would be a pretty tough sell I think.
That's true, but if say, Microsoft, wanted to, they could clearly create replacements for those services. Now, it's arguable whether an Android phone with Hotmail + Bing Maps integration is even an improvement, but at least it's possible.
In China, most Android phones are already sold without Google services: http://www.radiofreemobile.com/android-in-china-no-google-he...
In China, most Android phones are already sold without Google services: http://www.radiofreemobile.com/android-in-china-no-google-he...
You could say the same for GNU. What is Linux without a DE? And a fancy DE like GNOME Shell pulls in a lot of dependencies, the latest furore in that area is GNOME&systemd.
Difference between systemd and GMS is, developers aren't making money off of systemd being in their control, Google relies almost wholly on it for Android profits.
Android is a fully functional Linux based operating system. To expect GMS to just be handed out like it was a keg party flier without considering the actual economic reality of running Google is ridiculous.
OEMs like Samsung weren't fooled back in ~2004 to think they'd get an amazing OS for their phones for free, and the deal Google is offering is beyond amazing compared to how other (tech) firms do business. imo.
Difference between systemd and GMS is, developers aren't making money off of systemd being in their control, Google relies almost wholly on it for Android profits.
Android is a fully functional Linux based operating system. To expect GMS to just be handed out like it was a keg party flier without considering the actual economic reality of running Google is ridiculous.
OEMs like Samsung weren't fooled back in ~2004 to think they'd get an amazing OS for their phones for free, and the deal Google is offering is beyond amazing compared to how other (tech) firms do business. imo.
Wait, isn't GNOME a part GNU Project?
And Microsoft wouldn't be able to add similar integration?
What it comes down to is really "what do Android buyers expect from an Android device?"
If the consumers expect that they will get email, cloud storage, calendars, and maps then it would likely be fine for Microsoft to create similar integrations. If consumers expect that they will get Gmail, Google Drive, Google Calendars, and Google Maps, then they will likely be disappointed.
If the consumers expect that they will get email, cloud storage, calendars, and maps then it would likely be fine for Microsoft to create similar integrations. If consumers expect that they will get Gmail, Google Drive, Google Calendars, and Google Maps, then they will likely be disappointed.
Remember there are billions of people who haven't already been locked into Google services. They don't think "I need access to my years and gigabytes worth of Gmail." They think "I want email. This 'outlook.com' thing that came with my [hypothetical MS Android] phone will work fine"
Exactly - and isn't the Kindle Fire OS a successful Android fork?
How about, say, the location services apis, aren't they kind of needed for most apps?
You are thinking of Android as just an OS for consumer mobile phones. You don't always need Facebook to run on it for it to be useful. It is a great polished Linux distro that can find a lot of uses. Think of it as a specialized Linux without the GNU user space. It has a full rich and powerful API without relying on google.
Also device integrators are free to fork away from the base APIs to add their own functionality in the same way google has. If an app wants to be portable, they shouldn't build against these proprietary APIs. This isn't a unique problem to android and doesn't make the source any less open.
What I love so much about open source is that once a project is out there it can take on a life of its own. People can/have/will start cramming Android in places Google would have never expected. It makes a great base for POS systems, high end touch screen vending machines, in flight entertainment consoles, and any number of other things I can't think of but I'm sure the community will.
Also device integrators are free to fork away from the base APIs to add their own functionality in the same way google has. If an app wants to be portable, they shouldn't build against these proprietary APIs. This isn't a unique problem to android and doesn't make the source any less open.
What I love so much about open source is that once a project is out there it can take on a life of its own. People can/have/will start cramming Android in places Google would have never expected. It makes a great base for POS systems, high end touch screen vending machines, in flight entertainment consoles, and any number of other things I can't think of but I'm sure the community will.
Yes but the APIS themselves are open. It is possible to yank out the Google implementation of the location services and instead use a 3rd party implementation. The OS was designed to make something like this possible. Nokia could plug in their location services trivially for example if MSFT goes Android. (Not that I think it's a good idea but it's doable.)
There are other ways too - Sky hook for example seems to offer location services SDK http://www.skyhookwireless.com/location-technology/sdk.php for the Kindle Fire which doesn't ship with GApps.
There are other ways too - Sky hook for example seems to offer location services SDK http://www.skyhookwireless.com/location-technology/sdk.php for the Kindle Fire which doesn't ship with GApps.
Good point, but does this actually solve the "shortage of apps" problem if you don't have access to GMS and Google Play?
All this came up because of a couple of articles that said Microsoft should dump Windows Phone and do Android phones instead. So, would Microsoft have more problems getting developers to write for Windows Phone (and Windows 8 Metro) or for a forked version of Android?
Also, technically, you don't need an Android phone or tablet (or Linux) to run Andoid apps, since Bluestacks does this... though you might run into the same problem with GMS.
All this came up because of a couple of articles that said Microsoft should dump Windows Phone and do Android phones instead. So, would Microsoft have more problems getting developers to write for Windows Phone (and Windows 8 Metro) or for a forked version of Android?
Also, technically, you don't need an Android phone or tablet (or Linux) to run Andoid apps, since Bluestacks does this... though you might run into the same problem with GMS.
I used to work in Nokia's developer relations group. For a lot of developers, the following requirements are all hurdles that make WP more trouble than its worth:
- Learn a new language (C# is awesome but odds are the dev you are talking to already knows Java or ObjC. Telling an Android dev to learn C# is more work than telling him/her to tweak his/her Android app)
- Get Windows (a huge number of mobile devs are on MacBooks. Getting Windows costs some combination of time, money, and precious SSD space)
- Get Windows 8 (a lot people who are on Windows are on Windows 7 and have no desire to go to Windows 8)
bottom line: telling devs to tweak their Android apps for some kind of "MSMS" over GMS would represent a whole lot of lower barriers to entry.
- Learn a new language (C# is awesome but odds are the dev you are talking to already knows Java or ObjC. Telling an Android dev to learn C# is more work than telling him/her to tweak his/her Android app)
- Get Windows (a huge number of mobile devs are on MacBooks. Getting Windows costs some combination of time, money, and precious SSD space)
- Get Windows 8 (a lot people who are on Windows are on Windows 7 and have no desire to go to Windows 8)
bottom line: telling devs to tweak their Android apps for some kind of "MSMS" over GMS would represent a whole lot of lower barriers to entry.
Windows is on more than 90% of PCs (including a lot of Macs), Visual Studio is one of the most popular development environments, and C# is one of the most sought-after skills in the job market. And as others have noted, Xamarin for Visual Studio lets you develop for iOS and Android as well.
https://xamarin.com/visual-studio
Also, C# isn't compulsory because you can develop in HTML5 instead.
So, it might be impossible to get people who specialize in iOS apps to develop for WP8, but it should be possible to grow a comparable ecosystem. And making apps run on both W8 and WP8 would be a good move in that direction.
The short term view may be bleak but the future is uncertain, and the long term _could_ look different.
Also, C# isn't compulsory because you can develop in HTML5 instead.
So, it might be impossible to get people who specialize in iOS apps to develop for WP8, but it should be possible to grow a comparable ecosystem. And making apps run on both W8 and WP8 would be a good move in that direction.
The short term view may be bleak but the future is uncertain, and the long term _could_ look different.
Possibly, but just saying learn C# so you can program for Windows Phone is the wrong selling point. It should be learn C# so you can develop native-quality apps for all mobile platforms. Microsoft should completely embrace Xamarin. That would solve the OSX problem as well, as developers could use whatever OS and IDE they prefer.
Removing these barriers doesn't actually require forking Android, though. For example they could create a Java language projection for WinRT alongside the C++, .net and JavaScript ones. Actually just making the existing JavaScript stuff from Windows 8 available on WP might help a lot.
Amazon solved the lack of Google Play problem but their circumstances were very different.. Microsoft could technically do the same and they might have better app situation. Developer's problem with WP is that it is yet another platform to port their app to without any guarantee of returns given the platform's numbers. If MSFT went with their own Android store developers would just need minor changes to their Play Store version to gain yet another entry point. If it doesn't work out no big deal.
Problem is just going Android without great differentiation is almost a guaranteed failure for Microsoft. And at this stage in the game coming up with great differentiation is going to be very hard. But if they do something like put out great Nokia handset with great camera, guaranteed OS updates, a tiles based launcher an thriving alternate app store, more focus on privacy of the user and great Microsoft services and apps - that could work well. I am not sure about the practicaility of all that and if it will mean significantly more revenue for Microsoft. Besides, by all accounts Microsoft is still badly bullyish on the Windows everywhere strategy so to change course with Ballmer being the biggest share holder and Gates doing product advisor role it's just not easy. On top of that the market is just too irrational and hyper competitive for them to feel confident about doing something this drastic.
Problem is just going Android without great differentiation is almost a guaranteed failure for Microsoft. And at this stage in the game coming up with great differentiation is going to be very hard. But if they do something like put out great Nokia handset with great camera, guaranteed OS updates, a tiles based launcher an thriving alternate app store, more focus on privacy of the user and great Microsoft services and apps - that could work well. I am not sure about the practicaility of all that and if it will mean significantly more revenue for Microsoft. Besides, by all accounts Microsoft is still badly bullyish on the Windows everywhere strategy so to change course with Ballmer being the biggest share holder and Gates doing product advisor role it's just not easy. On top of that the market is just too irrational and hyper competitive for them to feel confident about doing something this drastic.
I'm running cyanogenmod without google and many of the apps out there rely on google apis without telling you that they do so (a significant chunk of the apps available on aptoide). Also with some phones that I've had it's been basically impossible to get a gps fix without enabling the 'allow google to track me' option, not that that is particularly relevant, but it is pretty annoying...
its not what makes an android phone and android phone.
so.. the argument is valid, android as a whole, coming from google, isn't open source. only AOSP is. And heck, even the AOSP maintainer resigned some time ago because AOSP didn't include open source drivers and what not.
It's somewhat analog to OSX. The kernel and low-level services are open-source and made publicly available on http://opensource.apple.com/. From that point and up, OSX is proprietary. Android would be somewhat analog to Darwin + Finder being open and iTunes, iPhoto, Mail and others being proprietary.
yeah, somewhat. that being said, AOSP does provide a little more than Darwin does, mainly, there is some UI provided. Otherwise, .. yeah. It's also getting closer and closer to that model.
It provides a lot more, otherwise Cyanogenmod wouldn't be possible. I have a cheap Huawei phone and replaced the annoying stock firmware with KitKat per Cyanogenmod and it's virtually impossible to see the differences compared to my Nexus 4 besides logo's and the extra features that Cyanogenmod has (I installed the Google Apps bundle).
At this point in time, it would be nearly impossible to make an open source, fully compatible, version of OS X. Replicating the APIs and user interface would probably cost hundreds of millions and a few patent lawsuits.
At this point in time, it would be nearly impossible to make an open source, fully compatible, version of OS X. Replicating the APIs and user interface would probably cost hundreds of millions and a few patent lawsuits.
as you said, you installed the google apps. well, google apps are 100 megs. guess why. Its not just gmail and what not. It includes all the proprietary APIs, everything.
You don't get any of that in AOSP. Reinstall CM but do not installed gapps, and you'll have something close to AOSP (well, better than AOSP still)
I bet you don't last a day before you'll install gapps again (and thus all the google proprietary libs, etc.)
You don't get any of that in AOSP. Reinstall CM but do not installed gapps, and you'll have something close to AOSP (well, better than AOSP still)
I bet you don't last a day before you'll install gapps again (and thus all the google proprietary libs, etc.)
>The "android isn't very open source" sentiment really bothers me and I see it a lot here.
>AOSP is open source.
Clever switch there from Android to AOSP, no wonder its the top comment. The difference between them is what the author is talking about. You just prove his point.
>AOSP is open source.
Clever switch there from Android to AOSP, no wonder its the top comment. The difference between them is what the author is talking about. You just prove his point.
It "bothers" you? How can it "bother" you? You arent an AOSP developer.
The license is not what the author is referring to, he's referring to the fact that YOU, or I or ANYONE cannot sign up to develop AOSP and contribute to the project because its just a code dump from google with a license.
Thats NOT open source and if you think the license makes it so then you need to go up and try to make a commit no matter how trivial to AOSP. Dont be a fool...fool.
The license is not what the author is referring to, he's referring to the fact that YOU, or I or ANYONE cannot sign up to develop AOSP and contribute to the project because its just a code dump from google with a license.
Thats NOT open source and if you think the license makes it so then you need to go up and try to make a commit no matter how trivial to AOSP. Dont be a fool...fool.
Not even Richard Stallman defines open source (or rather free software) like you do. [1] AOSP meets all of the criteria, and it's a code dump with a permissive license that you are free to fork and redistribute as you wish.
There's no rule that free software requires accepting pull requests from the entire world.
[1] https://www.gnu.org/philosophy/free-sw.html
There's no rule that free software requires accepting pull requests from the entire world.
[1] https://www.gnu.org/philosophy/free-sw.html
The beauty of open source is that Stallman doesnt really matter. There is no community developing around Android except for the google play store because to do so would be futile. (Yes I actually READ the article).
If a text blob of nonsense at the top of a source file makes you open source then WOW. How about Doge-Source? Such open, very free.
If a text blob of nonsense at the top of a source file makes you open source then WOW. How about Doge-Source? Such open, very free.
I don't have much to say about the forking issue, but it want to say this: I own and LOVE my Windows Phone (Nokia Lumia 822). I started on android (Droid X) after deciding the iPhone was too small, bought another one (Droid Razr Maxx), and finally ended up at Windows Phone after playing with it on some online simulator.
I wouldn't go back to android or ios. I don't think they're as usable or fit me as well.
Anecdotally, my wife also joined me on Windows Phone recently after dropping her android phone. She started on iPhone, lost it, was gifted my Razr Maxx, then broke it. She liked the UI of ios, but loved Swype on android and said she'd never go back to ios. Then while we waited a couple weeks for our phone upgrade, she played with my phone and ended up really liking it. She now says it is her favorite phone (Nokia Lumia 920). She likes the camera and the excellent apps from Nokia.
Obviously I don't want MS to switch to android. There may be more apps, but so many are of such poor quality that it is entirely irrelevant to me. Same goes for the apple store. It's almost overwhelming how many bad apps there are.
I wouldn't go back to android or ios. I don't think they're as usable or fit me as well.
Anecdotally, my wife also joined me on Windows Phone recently after dropping her android phone. She started on iPhone, lost it, was gifted my Razr Maxx, then broke it. She liked the UI of ios, but loved Swype on android and said she'd never go back to ios. Then while we waited a couple weeks for our phone upgrade, she played with my phone and ended up really liking it. She now says it is her favorite phone (Nokia Lumia 920). She likes the camera and the excellent apps from Nokia.
Obviously I don't want MS to switch to android. There may be more apps, but so many are of such poor quality that it is entirely irrelevant to me. Same goes for the apple store. It's almost overwhelming how many bad apps there are.
my partner owns a nokia lumia.
She loves it, but it has had to be taken back to the shop we bought it from twice so far, because apparently everytime Microsoft releases an upgrade, it effectively bricks the device during the install attempt.
It amazes me how badly Microsoft seems to manage its software compared to Apple.
OTOH, she does love it.
She loves it, but it has had to be taken back to the shop we bought it from twice so far, because apparently everytime Microsoft releases an upgrade, it effectively bricks the device during the install attempt.
It amazes me how badly Microsoft seems to manage its software compared to Apple.
OTOH, she does love it.
What feature or features of Windows Phone drive you to love it? How would you to describe the experience in relation to Android or iOS?
Are there multiple web browser options?
Are there multiple web browser options?
Honestly IE on WP8 is a great experience so I haven't felt the need to look but no, all browsers use IE on the phone.
And for me the key feature is everything just works. Theres no need or feeling that I need to flash a rom (which I felt I has to do endlessly on Android). The integration with the ecosystem is nice, sure it's missing some core features iOS and Android have after years of beating MS to the market but hopefully it'll show up.
The major thing its missing is device integration, my fitbit not syncing saddens me everyday and theres not much I can do about it.
And for me the key feature is everything just works. Theres no need or feeling that I need to flash a rom (which I felt I has to do endlessly on Android). The integration with the ecosystem is nice, sure it's missing some core features iOS and Android have after years of beating MS to the market but hopefully it'll show up.
The major thing its missing is device integration, my fitbit not syncing saddens me everyday and theres not much I can do about it.
Live tiles, arranging my start screen to show exactly what I want without having to open any apps, I think is the single biggest feature that I love about WP. I also love the text prediction and correction when typing. I haven't seen any other mobile OS do it as well.
Android and iOS are pretty much one and the same for me. They do similar things and they come stock with a very similar UI. I'm not big on the list of icons/folders and multiple pages setup.
Regarding ios7, I don't like the new text-as-button thing they have going. It's hard to find them sometimes. I also really dislike the difference in pre-ios7 apps and ios7 apps as far as UI goes. It's jarring to me. It'd be like having a windows XP window pop up in Windows 8, or an OS9 window pop up in OSX.
I am also not a fan of the all-caps ios keyboard. Windows Phone keyboard displays the characters exactly as they're about to appear, but in ios they are always capitals (just differently sized) and it makes for a good bit of errors for me. I still have an ipad with ios7, so I interact with it second-most of all mobile operating systems.
Android and iOS are pretty much one and the same for me. They do similar things and they come stock with a very similar UI. I'm not big on the list of icons/folders and multiple pages setup.
Regarding ios7, I don't like the new text-as-button thing they have going. It's hard to find them sometimes. I also really dislike the difference in pre-ios7 apps and ios7 apps as far as UI goes. It's jarring to me. It'd be like having a windows XP window pop up in Windows 8, or an OS9 window pop up in OSX.
I am also not a fan of the all-caps ios keyboard. Windows Phone keyboard displays the characters exactly as they're about to appear, but in ios they are always capitals (just differently sized) and it makes for a good bit of errors for me. I still have an ipad with ios7, so I interact with it second-most of all mobile operating systems.
Do you think an alternative launcher for Android that featured a similar approach to live tiles would capture that advantage? As opposed to all the Newton/Palm style launchers out there.
I suppose they could, but every good launcher I had on android wanted donations or an up-front + theme fee. The best android devices are really expensive, whereas you can get a brand new windows phone for wicked cheap (mine was $50 when I got it, my wife's was free).
For me, it's the design of Metro UI.
I remember the first WIMP computer I had (well my dad had) an A5000, with 4mb of RAM (this had to be soldered on, and was considered wantantly excessive). If I wanted 256 colours, resolution would suffer as it lacked VRAM.
Windows 98 had gradient title bars, I this was a big deal. I remember being impressed by how smooth it looked. I wasn't completely used to high resolution, high colour systems.
Metro shuns this, information is put above anything else, the fact that I only want to see my mobile signal if I've a problem by default, it is hidden unless I have none.
It doesn't take long before this really starts to make sense. I'm tired, I don't want to be bamboozled by information, I want important stuff put up above anything else.
It's exactly the same reason Web Browsers have 'hidden' away the lesser used functions. I type this on a desktop with 2 * 30" of screen real estate, yet I still want my browser to hide the file menu, have no favourites bar, not waste space for the tabs and the title bar. You get where I'm going with this.
I also have a few Android devices, and a iPad, I find it almost tiring to use them in a way, I'm no longer impressed by having a 3d glass effect or similar, it just impedes my usability. I don't like skeuomorphic patterns, I'm an veteran user, I don't need familiarity, I want information presented as effortlessly as possible.
That said, I hate the lack of a notification timeline. I am genuinely saddened to see how Windows Phone team appears to have lost their release cycle momentum (three years ago major features came fast and frequent, now... not much).
I remember the first WIMP computer I had (well my dad had) an A5000, with 4mb of RAM (this had to be soldered on, and was considered wantantly excessive). If I wanted 256 colours, resolution would suffer as it lacked VRAM.
Windows 98 had gradient title bars, I this was a big deal. I remember being impressed by how smooth it looked. I wasn't completely used to high resolution, high colour systems.
Metro shuns this, information is put above anything else, the fact that I only want to see my mobile signal if I've a problem by default, it is hidden unless I have none.
It doesn't take long before this really starts to make sense. I'm tired, I don't want to be bamboozled by information, I want important stuff put up above anything else.
It's exactly the same reason Web Browsers have 'hidden' away the lesser used functions. I type this on a desktop with 2 * 30" of screen real estate, yet I still want my browser to hide the file menu, have no favourites bar, not waste space for the tabs and the title bar. You get where I'm going with this.
I also have a few Android devices, and a iPad, I find it almost tiring to use them in a way, I'm no longer impressed by having a 3d glass effect or similar, it just impedes my usability. I don't like skeuomorphic patterns, I'm an veteran user, I don't need familiarity, I want information presented as effortlessly as possible.
That said, I hate the lack of a notification timeline. I am genuinely saddened to see how Windows Phone team appears to have lost their release cycle momentum (three years ago major features came fast and frequent, now... not much).
I also have a Lumia that I use as a secondary phone. The device is nice, Nokia can surely make good hardware, however my problem is the OS.
The Metro UI is kind of nice, but it gets obnoxious. I've began to hate those animations. And when I do need in-your-face notifications, like for the weather or something, you don't have the nice widgets that you get with Android.
Also, Microsoft is in charge of the Facebook app and I don't get how in the world they managed to treat the login in that Facebook app as something separate than the phone's accounts. I also want to be able to manage what accounts are synchronized or not - because synchronization uses battery, plus notifications are annoying and for many accounts I only want to view the latest messages or whatever only when I open the app - and haven't found an option for doing so, unless you turn the battery savings on. While we are on the subject, the notifications bar is a joke.
The app store is full of crap. Microsoft has played the app numbers game, allowing some genuine crap in their store. Of course, both Google Play and iTunes are filled with crap, but the search and the ratings are usually enough for finding good stuff and both Google Play and iTunes also have very polished, very good apps for everything.
But the above don't really bother me as much as my last point - Windows Phone is at its core as restrictive as iOS. It does not allow installs of apps from third party sources and is basically defective by design ... for example, to do Wifi tethering, the mobile career has to wire you the settings that allow it. And it's been a PITA for me, because my mobile career couldn't wire me the settings automatically, since they don't have my phone model in their database. Isn't that awesome?
The Metro UI is kind of nice, but it gets obnoxious. I've began to hate those animations. And when I do need in-your-face notifications, like for the weather or something, you don't have the nice widgets that you get with Android.
Also, Microsoft is in charge of the Facebook app and I don't get how in the world they managed to treat the login in that Facebook app as something separate than the phone's accounts. I also want to be able to manage what accounts are synchronized or not - because synchronization uses battery, plus notifications are annoying and for many accounts I only want to view the latest messages or whatever only when I open the app - and haven't found an option for doing so, unless you turn the battery savings on. While we are on the subject, the notifications bar is a joke.
The app store is full of crap. Microsoft has played the app numbers game, allowing some genuine crap in their store. Of course, both Google Play and iTunes are filled with crap, but the search and the ratings are usually enough for finding good stuff and both Google Play and iTunes also have very polished, very good apps for everything.
But the above don't really bother me as much as my last point - Windows Phone is at its core as restrictive as iOS. It does not allow installs of apps from third party sources and is basically defective by design ... for example, to do Wifi tethering, the mobile career has to wire you the settings that allow it. And it's been a PITA for me, because my mobile career couldn't wire me the settings automatically, since they don't have my phone model in their database. Isn't that awesome?
I use Amazing Weather hd as my lock screen, which takes care of the weather issue for me. But as far as other live tiles, you can turn any of them off if you want. I mean, you COULD just make a start screen that looked like android/ios with a ton of icons if you really wanted to.
I don't use Facebook so I can't comment on that, but most apps I've used (twitter, linkedin, hacker news, readit) have settings for syncing. I only let readit sync in the background personally.
The notifications bar itself is only there for a few seconds, so I'm not sure what issue you could possibly have with it. Notifications appear on the app tiles themselves, which I prefer (especially for when I add a person to my start screen and they call/text/email me). It doesn't function the same way as android/ios, but I prefer it.
Every App Store is full of garbage, there's no denying it. I've found the windows App Store much easier to wade through, though. It's still far below the amount of apps in the android/ios stores, and the few top rated apps are almost always the official (or best) apps. I haven't found an issue with apps, but it am not a huge app guy. I mostly use twitter and readit (for reddit, obviously).
I haven't faced any issues like your last one either, so I can't really comment. I have verizon and they have next to no support for windows phone, so I could see it happening.
I don't use Facebook so I can't comment on that, but most apps I've used (twitter, linkedin, hacker news, readit) have settings for syncing. I only let readit sync in the background personally.
The notifications bar itself is only there for a few seconds, so I'm not sure what issue you could possibly have with it. Notifications appear on the app tiles themselves, which I prefer (especially for when I add a person to my start screen and they call/text/email me). It doesn't function the same way as android/ios, but I prefer it.
Every App Store is full of garbage, there's no denying it. I've found the windows App Store much easier to wade through, though. It's still far below the amount of apps in the android/ios stores, and the few top rated apps are almost always the official (or best) apps. I haven't found an issue with apps, but it am not a huge app guy. I mostly use twitter and readit (for reddit, obviously).
I haven't faced any issues like your last one either, so I can't really comment. I have verizon and they have next to no support for windows phone, so I could see it happening.
Aren't in-your-face widgets the biggest thing in the Windows phone UI? Those big tiles in all the ads? I seem to be confused.
Dianne Hackborn (who works on Android) responds in the comments:
http://arstechnica.com/information-technology/2014/02/neithe...
http://arstechnica.com/information-technology/2014/02/neithe...
Oh, another Peter Bright ("Microsoft Editor at Ars Technica") clickbait article. Yay.
The author of such fine pieces as:
"Firefox ships, but we shouldn’t really pay attention"
"Android OEMs should hear Microsoft, Nokia out on Google-Motorola combo"
"Android tablets may provide sales, but profitability is another matter."
etc
Sadly, judging by the old argument rehash going on here so far, it looks like it's working :(
"Firefox ships, but we shouldn’t really pay attention"
"Android OEMs should hear Microsoft, Nokia out on Google-Motorola combo"
"Android tablets may provide sales, but profitability is another matter."
etc
Sadly, judging by the old argument rehash going on here so far, it looks like it's working :(
Hm. It sounds a little like Google would be doing really bad to seize control over their infrastructure. But since they do, the whole Android world has improved, at least in my opinion. Think about the upgrade complains we had a few years back. As far as I know that's gone now.(?) So I think it's actually good what Google is doing in that regard.
From my own experience with developing FOSS is also that other people don't try to integrate their solutions into your system. Everybody heads off and makes their own stuff.
Stupid forking is no problem for a project like GCC. But Android is a brand name. And if other people fork it and head off doing their own stuff and fail, then it is always Android that fails.
And really as a developer I also fight for the freedom of software, but as an end user I want to be able to go to a shop and buy an "Android phone" and it just works. Therefore, yes, please, Google take control! Good job!
From my own experience with developing FOSS is also that other people don't try to integrate their solutions into your system. Everybody heads off and makes their own stuff.
Stupid forking is no problem for a project like GCC. But Android is a brand name. And if other people fork it and head off doing their own stuff and fail, then it is always Android that fails.
And really as a developer I also fight for the freedom of software, but as an end user I want to be able to go to a shop and buy an "Android phone" and it just works. Therefore, yes, please, Google take control! Good job!
Has Microsoft, Nokia, etc considered some kind of app api bridge or outright code converter tool for Android/Java apps into their own native SDKs?
Seems that if a lack of apps is your main problem then easing the time to port an app to your ecosystem should be a high priority. Sure you'd have to re-implement some proprietary api features, but they likely already have equivalents in the Windows phone SDK (location services, in-app purchasing, etc).
Seems that if a lack of apps is your main problem then easing the time to port an app to your ecosystem should be a high priority. Sure you'd have to re-implement some proprietary api features, but they likely already have equivalents in the Windows phone SDK (location services, in-app purchasing, etc).
AOSP is open source, period. Just because Google apps aren't doesn't make the entire thing closed.
The binary blobs and baseband firmware might as well be on any "open" phone. The issue here is not whether Android phones are open or not, it's whether phones in general can truly be "open" or not.
There's a response from Dianne Hackborn (hackbod) of Android.
http://arstechnica.com/information-technology/2014/02/neithe...
http://arstechnica.com/information-technology/2014/02/neithe...
Not having Google Play hasn't limited my Kindle Fire experience so far. All the important apps are on the Amazon store, and most of the rest are low quality IAP bait.
Interesting article. I'm intrigued as to how CynaogenMod handles the lack of Google Play APIs - it seems to be skirted around on their website.
If you run it on your existing phone then it extracts the Google Play apps from it and re-uploads them afterwards.
However, their new phone is actually certified, and therefore gets them "properly": http://www.androidpolice.com/2013/12/19/the-oppo-n1-is-offic...
However, their new phone is actually certified, and therefore gets them "properly": http://www.androidpolice.com/2013/12/19/the-oppo-n1-is-offic...
Woha that looks pretty good. I didn't know about the Oppo N1.
Microsoft is just not going to abandon Windows Phone, for fundamentally these reasons:
"If it's a core business function – do it yourself, no matter what." http://www.codinghorror.com/blog/2008/10/programming-is-hard...
MS certainly will view "a computer in every pocket, and all of them running MS Software" as core to their future. If they do abandon Windows phone, it will be because that has changed.
In the meantime, MS is a company with a track record of plugging away until version x of the product is good enough to succeed.
"If it's a core business function – do it yourself, no matter what." http://www.codinghorror.com/blog/2008/10/programming-is-hard...
MS certainly will view "a computer in every pocket, and all of them running MS Software" as core to their future. If they do abandon Windows phone, it will be because that has changed.
In the meantime, MS is a company with a track record of plugging away until version x of the product is good enough to succeed.
"all of them running MS software" is already never going to happen. If they view that as core to their future, they have already failed.
What needs to happen is that the definition of "running MS software" needs to change from an OS stack (where they've already lost) to things going on in the cloud.
What needs to happen is that the definition of "running MS software" needs to change from an OS stack (where they've already lost) to things going on in the cloud.
I don't think that battle is settled (or that it will have winners and losers at all).
I don't think it's quite that settled.
And no, it's not just about the OS stack. It says something that MS's new CEO, Satya Nadella, used to run the cloud group.
And no, it's not just about the OS stack. It says something that MS's new CEO, Satya Nadella, used to run the cloud group.
You forget "Embrace, extend . . "
The other mobile ecosystems are now so far in front they have no viable option other than the embracing and extending. Android happens to be flexible enough at the software layer (not just licensing) to make such a thing remarkably easy to do, given the resources.
The other mobile ecosystems are now so far in front they have no viable option other than the embracing and extending. Android happens to be flexible enough at the software layer (not just licensing) to make such a thing remarkably easy to do, given the resources.
> The other mobile ecosystems are now so far in front they have no viable option other than the embracing and extending.
That's your opinion. I doubt that it would get any traction inside MS.
It just doesn't make sense - are MS more likely to take the android kernel and reskin it to look like WinPhone, or continue to believe that writing OS kernels is a core company competence ... which it is, really. If one day MS could not write OS kernels any more they would be in serious trouble. It's a core business function, so they do it themselves.
How would re-skinning android help MS get "in front" anyway? They have technically solid product in Windows Phone, they need other things to make it win, and they know it. Hence, the whole Nokia deal.
That's your opinion. I doubt that it would get any traction inside MS.
It just doesn't make sense - are MS more likely to take the android kernel and reskin it to look like WinPhone, or continue to believe that writing OS kernels is a core company competence ... which it is, really. If one day MS could not write OS kernels any more they would be in serious trouble. It's a core business function, so they do it themselves.
How would re-skinning android help MS get "in front" anyway? They have technically solid product in Windows Phone, they need other things to make it win, and they know it. Hence, the whole Nokia deal.
"they need other things" - like the extremely strong app eco-system of Android (in comparison to Windows Phone, specifically). WP is a strong OS with some great design choices etc (IMO, obviously); it's main downfall from my point of view is the lack of apps. Forking Android (not necessarily just "skinning" but a step beyond that) is an obvious solution to that issue.
The entire article is all about how it's not really an obvious solution at all. Amazon is forking Android, and they have rewritten many of the GMS APIs, and yet, many of the apps do not run on Kindle Fire like they do on Android.
There's almost no value add in a custom kernel from a customer perspective. MS don't so much sell Windows as Office, Exchange etc. These are whole platforms in and of themselves. Android is flexible enough to enable MS service clients to sit on top of it and act as if they're built in to the system, while getting easy portability for all the existing Android developers. (This is the point I think most objectors underestimate, since Android is a giant mess, but has an inspired way for plugging apps together at runtime).
Windows as a standalone product is essentially dead, but selling it as part of a system for running Outlook, Exchange and Excel is not and won't be for a long while.
Windows as a standalone product is essentially dead, but selling it as part of a system for running Outlook, Exchange and Excel is not and won't be for a long while.
> There's almost no value add in a custom kernel from a customer perspective. MS don't so much sell Windows as Office, Exchange etc.
True, the OS kernel is an enabler not a feature.
> Windows as a standalone product is essentially dead
And on the server world it's a platform for IIS servers, SQL servers, and azure clouds.
Yes, a company that does this could decide to use someone else's OS kernel to enable all that. The original article that I linked to in grandparent comment explains why that would be a dangerous decision and is not going to happen.
True, the OS kernel is an enabler not a feature.
> Windows as a standalone product is essentially dead
And on the server world it's a platform for IIS servers, SQL servers, and azure clouds.
Yes, a company that does this could decide to use someone else's OS kernel to enable all that. The original article that I linked to in grandparent comment explains why that would be a dangerous decision and is not going to happen.
I'm afraid your link merely shows the misguided point-of-view leading to the MS malaise.
Look at your examples for server stuff: it would make no difference to the end user if those were running on Windows or not. IIS gets value from ease of .net application deployment, SQL server from playing well with .net, and Azure can deploy Linux because that department can't afford not to be in the embrace/extending mode.
From an MS point of view making the OS might make these things easier to deploy, but just because you're good at doing something doesn't mean other people are going to keep paying you to do it, and so it will be with Windows. MS are going to end up disadvantaging themselves given they have to duplicate a lot of work going on in the open source community.
If you use Chrome in Metro mode on a Win8 machine you'll see the extent to which Google are outplaying MS, as it apes the Chrome OS experience completely. Google are leveraging the Windows user base to reduce friction to them eventually moving to Chrome OS.
Look at your examples for server stuff: it would make no difference to the end user if those were running on Windows or not. IIS gets value from ease of .net application deployment, SQL server from playing well with .net, and Azure can deploy Linux because that department can't afford not to be in the embrace/extending mode.
From an MS point of view making the OS might make these things easier to deploy, but just because you're good at doing something doesn't mean other people are going to keep paying you to do it, and so it will be with Windows. MS are going to end up disadvantaging themselves given they have to duplicate a lot of work going on in the open source community.
If you use Chrome in Metro mode on a Win8 machine you'll see the extent to which Google are outplaying MS, as it apes the Chrome OS experience completely. Google are leveraging the Windows user base to reduce friction to them eventually moving to Chrome OS.
Look at your examples for server stuff: it would make no difference to the end user if those were running on Windows or not. IIS gets value from ease of .net application deployment, SQL server from playing well with .net
IIS also gets value from Windows account permissions integration, from Computer Manager integration and MS Best practises Analyser, from PowerShell and VBScript and Visual studio integration, from Windows certificate services integration, blah blah.
The "Windows" benefit is integration, Microsoft products aren't standalone.
What benefit rewriting everything for Linux? Except alienating a huge chunk of Linux-ambivalent administrators.
IIS also gets value from Windows account permissions integration, from Computer Manager integration and MS Best practises Analyser, from PowerShell and VBScript and Visual studio integration, from Windows certificate services integration, blah blah.
The "Windows" benefit is integration, Microsoft products aren't standalone.
What benefit rewriting everything for Linux? Except alienating a huge chunk of Linux-ambivalent administrators.
> I'm afraid your link merely shows the misguided point-of-view
I agree that it is MS's point of view on this topic. We're going to have to disagree that it's "misguided". IMHO Jeff Atwood was right on the mark in that essay, and it applies to this case.
Will it be enough for MS and for Windows Phone in particular? I don't claim to know. Would swapping over to android help? Unlikely, once you factor in the loss of face involved. Are others like Google doing it better? Probably.
I agree that it is MS's point of view on this topic. We're going to have to disagree that it's "misguided". IMHO Jeff Atwood was right on the mark in that essay, and it applies to this case.
Will it be enough for MS and for Windows Phone in particular? I don't claim to know. Would swapping over to android help? Unlikely, once you factor in the loss of face involved. Are others like Google doing it better? Probably.
> You forget "Embrace, extend . . "
Like Apple, Oracle, IBM and many other commercial vendors. Still don't get why only Microsoft gets bashed about it.
Like Apple, Oracle, IBM and many other commercial vendors. Still don't get why only Microsoft gets bashed about it.
To be clear, I'm not bashing - it's clearly a good business strategy, and confusing that current MS appears to have forgotten it.
Google are currently showing how it's done perfectly.
Google are currently showing how it's done perfectly.
Faire enough, I just complained, because it is quite common in places like HN to bash Microsoft, while forgetin about similar practices done by other companies, just because they enjoy a few more geek points.
Its really only common because Microsoft did so well with it compared to the rest. Its not like we "forget" other companies do it, just that they haven't done nearly as well as microsoft in their heyday.
When the next big thing comes and threatens Google, then we will see how well they will do. So far they raised and shined without much trouble.
"Embrace, extend" was more effective (and terrifying to competition) when Microsoft was the juggernaut. But now Microsoft is actually behind Google, so there's little chance they can extend it any meaningful way that would give them leverage against Google. Google has equal engineering resource and huge head-start in install base and ecosystem.
So the real question is what could Microsoft leverage from AOSP? My instinct is they could probably build anything from AOSP into WinPhone far faster than they could utilize AOSP directly.
So the real question is what could Microsoft leverage from AOSP? My instinct is they could probably build anything from AOSP into WinPhone far faster than they could utilize AOSP directly.
Your instincts are wrong, but I've run into this misconception a lot. Nokia made this error, and RIM/Blackberry are doing it all over again.
All they have to do to use AOSP is 1. start using it, 2. develop apps which are clients for their services, and 3. release a device with those clients preinstalled. There is no magic hidden step.
Everything from the accounts system, inter app communication, billing, push, is pluggable and they already have the servers for most of it setup, which is far and away the hardest part.
All they have to do to use AOSP is 1. start using it, 2. develop apps which are clients for their services, and 3. release a device with those clients preinstalled. There is no magic hidden step.
Everything from the accounts system, inter app communication, billing, push, is pluggable and they already have the servers for most of it setup, which is far and away the hardest part.
Yes, but what does that benefit them? There's very little money in being an Android reseller, even if you're driving traffic to your services.
You could ask the same question of Google. Clearly, Google thinks there's money in using Android to drive traffic to their services.
That OS will not be compatible with Android apps, neither have access to the market. What's the benefit over Windows phone?
Why do you think apps wouldn't be compatible? It would be just like Amazon - yes, you'd need to run a new store (fairly trivial for an MS or Nokia type org to get going) and need a new billing API, but that's all you'd need to get going.
To put this in perspective moving Play Store builds to the Amazon store is generally a matter of replacing the billing and push APIs, if you've used them, which takes a few hours. (If you've used game services it might take longer, but again it's not actually hard). This is far easier than redeveloping your app completely for a different platform.
I've been involved with apps for which the move to Amazon was simply a 10 minute boot up on a Kindle Fire to establish it worked.
To put this in perspective moving Play Store builds to the Amazon store is generally a matter of replacing the billing and push APIs, if you've used them, which takes a few hours. (If you've used game services it might take longer, but again it's not actually hard). This is far easier than redeveloping your app completely for a different platform.
I've been involved with apps for which the move to Amazon was simply a 10 minute boot up on a Kindle Fire to establish it worked.
Have you ever used the Nokia app store? Either it's not as trivial to build as you think, or Nokia kinda stinks at it.
Haha! I had to make stuff for Ovi once.
Nokia are bad at it, but you might recall the N-Gage that had a services layer that wasn't completely terrible. In Europe the operators usually ran this stuff, at least pre-Apple/Google, and there were a good few companies that existed by selling portals which were white labelled and branded as the operator stores.
These things certainly can be killed in bureaucracy, but the tech issues aren't too bad, especially if you're already sitting on a giant pile of servers and a billing solution for each country. At one point I knew one team running stores for about 20 operators (each country is essentially separate) with less than that in developers, and only a handful of sysadmins, if you can have such a thing.
Nokia are bad at it, but you might recall the N-Gage that had a services layer that wasn't completely terrible. In Europe the operators usually ran this stuff, at least pre-Apple/Google, and there were a good few companies that existed by selling portals which were white labelled and branded as the operator stores.
These things certainly can be killed in bureaucracy, but the tech issues aren't too bad, especially if you're already sitting on a giant pile of servers and a billing solution for each country. At one point I knew one team running stores for about 20 operators (each country is essentially separate) with less than that in developers, and only a handful of sysadmins, if you can have such a thing.
I'm not sure what misconception your think I have, but it has nothing to do with how easy or hard AOSP is to use. It's the fact that Microsoft already has a good mobile phone OS tied into their ecosystem. What does AOSP bring to the table that is going to move the needle for them?
Even better, Microsoft already license the Exchange protocols to Google and Apple, and then they get to pay Microsoft and do the work of integrating their mail and calendaring software with Exchange.
http://www.microsoft.com/en-us/legal/intellectualproperty/IP...
http://www.microsoft.com/en-us/legal/intellectualproperty/IP...
Embrace extend works for markets and technologies not so much for operating systems. Nobody has done well embracing and extending Android, those who tried such as Samsung are throwing in the towel because of...
...wait for it...
...you know it's coming...
...vendor lock-in.
I think the article gives Android too much credit for mindshare. Sure it's a platform for developers (this is why the monkey boy criticism of Ballmer makes no sense) but it's not really a brand among consumers. In consumer minds, Android is simply not an iPhone and increasingly not a Windows Phone. All that manufacturer and carrier customization erodes the idea of Android. In so far as Android is a brand, it's Google, not Andorid. But the primary brand of an Android phone is the Phone's manufacturer. Doing Apple on the cheap doesn't work.
...wait for it...
...you know it's coming...
...vendor lock-in.
I think the article gives Android too much credit for mindshare. Sure it's a platform for developers (this is why the monkey boy criticism of Ballmer makes no sense) but it's not really a brand among consumers. In consumer minds, Android is simply not an iPhone and increasingly not a Windows Phone. All that manufacturer and carrier customization erodes the idea of Android. In so far as Android is a brand, it's Google, not Andorid. But the primary brand of an Android phone is the Phone's manufacturer. Doing Apple on the cheap doesn't work.
Isn't Kindle Fire OS a perfect example of embrace and extend? Sure, it's also vendor lock in, but a good example that you can fork Android without relying on Google's services.
Hmm. What if MS made a .NET to dex converter???
I'm in the MS hating camp, BUT, I suppose they could actually devote enough resources to make a quite usable mode in Visual Studio that supports a .NET subset that maps to the Android/base API and then translates .NET bytecode to dex/dalvik format.
Oh, the horror...
I'm in the MS hating camp, BUT, I suppose they could actually devote enough resources to make a quite usable mode in Visual Studio that supports a .NET subset that maps to the Android/base API and then translates .NET bytecode to dex/dalvik format.
Oh, the horror...
Xamarin allows you to use Visual Studio and .NET/Mono to target Android and other platforms. [1]
dot42 focuses on Android exclusively and targets dex/dalvik instead of the Mono runtime. [2]
[1] http://xamarin.com/ [2] https://www.dot42.com
dot42 focuses on Android exclusively and targets dex/dalvik instead of the Mono runtime. [2]
[1] http://xamarin.com/ [2] https://www.dot42.com
Agreed, although that track record stopped pretty much after IE and XBox.
It's still happening, Azure is being iterated and improved a lot.
This has been an ongoing cycle for all of Android. First people complain about Android lagging behind iOS so Google starts moving their services to GSM so they can avoid having to send updates through manufacturers. Then people complain Google isn't open enough so they start baking it into ASOP which takes forever to rollout. On the cycle goes..
It doesn't have to be either or. Most of the AOSP apps have been basically abandoned. They could develop the AOSP Calendar app and also put a branded version in GSM. But they aren't doing that.
This has been thrown around a lot, but it's not really the case when you look into it. Going to through the 9 base apps of the CDD and comparing to Nexus:
Clock: https://android.googlesource.com/platform/packages/apps/Desk... - still worked on, identical
Browser: https://android.googlesource.com/platform/packages/apps/Brow... bug fixes only, but it was just a wrapper over webview. With chromium taking over webview any 3rd party/OEM browser app based on it essentially is a Chrome fork.
Calendar - https://android.googlesource.com/platform/packages/apps/Cale... Still worked on, identical except the built-in Google Calendar Content Provider/sync and alt icon
Contacts (People): https://android.googlesource.com/platform/packages/apps/Cont... - Still worked on, identical.
Gallery: https://android.googlesource.com/platform/packages/apps/Gall... - Still worked on/huge update in 4.4, identical.
Search: https://android.googlesource.com/platform/packages/apps/Quic... - Bug fixes, terrible 2.x style design, no Now.
Launcher: https://android.googlesource.com/platform/packages/apps/Laun... - Still worked on, doesn't include Google Now page or hotword detection
Music: https://android.googlesource.com/platform/packages/apps/Musi... Bugfixes, terrible 2.x design.
Settings: https://android.googlesource.com/platform/packages/apps/Sett... - Still worked on, identical
And to throw in three more essentials:
Keyboard: https://android.googlesource.com/platform/packages/inputmeth... - Still worked on. No Swipe input, identical otherwise
Camera: https://android.googlesource.com/platform/packages/apps/Came... - Still worked on. No Photosphere, identical otherwise
Email: https://android.googlesource.com/platform/packages/apps/Emai... - Still worked on, identical. Post-4.4 its design matches the Gmail app.
Each of the omissions has either an obvious Google server dependency (Google Now) or possible patent liability angle (the Swipe keyboard functionality). Music and Search are the only two which really stick out.
But even with Music, there's an argument to be made about the opportunity cost of doing so. There's no immediate benefit in spending dev cycles prettying up the AOSP Music app when no consumer will see it since every major OEM (Samsung, HTC, Sony etc) already have their own. Any time they set aside to that is time they could have used to work on the terrible latency problems plaguing the underlying audio system, which actually does make a difference across the board.
The same applies to Search. It's much more effective to commit those dev cycles on the layers underlying it so that the whole ecosystem benefits. Few of the exclusive features of the current Google Search app make sense for a service agnostic device search app to have, which is the original role of that app plays (Google's OS X app of the same name had the same featureset: http://www.google.com/quicksearchbox/). Really there's no motive to subvert the order of things and promote web search over OS search in a OS search app unless you own a search engine like Google.
Which isn't to say it (and Music) shouldn't be updated, since they do serve as docs for 3rd party devs and OEMs, so not updating would have some indirect inverse effect on the quality of apps. But I can see why they haven't got around to it yet given their trajectory.
tl;dr the situation is more grey than black or white.
Clock: https://android.googlesource.com/platform/packages/apps/Desk... - still worked on, identical
Browser: https://android.googlesource.com/platform/packages/apps/Brow... bug fixes only, but it was just a wrapper over webview. With chromium taking over webview any 3rd party/OEM browser app based on it essentially is a Chrome fork.
Calendar - https://android.googlesource.com/platform/packages/apps/Cale... Still worked on, identical except the built-in Google Calendar Content Provider/sync and alt icon
Contacts (People): https://android.googlesource.com/platform/packages/apps/Cont... - Still worked on, identical.
Gallery: https://android.googlesource.com/platform/packages/apps/Gall... - Still worked on/huge update in 4.4, identical.
Search: https://android.googlesource.com/platform/packages/apps/Quic... - Bug fixes, terrible 2.x style design, no Now.
Launcher: https://android.googlesource.com/platform/packages/apps/Laun... - Still worked on, doesn't include Google Now page or hotword detection
Music: https://android.googlesource.com/platform/packages/apps/Musi... Bugfixes, terrible 2.x design.
Settings: https://android.googlesource.com/platform/packages/apps/Sett... - Still worked on, identical
And to throw in three more essentials:
Keyboard: https://android.googlesource.com/platform/packages/inputmeth... - Still worked on. No Swipe input, identical otherwise
Camera: https://android.googlesource.com/platform/packages/apps/Came... - Still worked on. No Photosphere, identical otherwise
Email: https://android.googlesource.com/platform/packages/apps/Emai... - Still worked on, identical. Post-4.4 its design matches the Gmail app.
Each of the omissions has either an obvious Google server dependency (Google Now) or possible patent liability angle (the Swipe keyboard functionality). Music and Search are the only two which really stick out.
But even with Music, there's an argument to be made about the opportunity cost of doing so. There's no immediate benefit in spending dev cycles prettying up the AOSP Music app when no consumer will see it since every major OEM (Samsung, HTC, Sony etc) already have their own. Any time they set aside to that is time they could have used to work on the terrible latency problems plaguing the underlying audio system, which actually does make a difference across the board.
The same applies to Search. It's much more effective to commit those dev cycles on the layers underlying it so that the whole ecosystem benefits. Few of the exclusive features of the current Google Search app make sense for a service agnostic device search app to have, which is the original role of that app plays (Google's OS X app of the same name had the same featureset: http://www.google.com/quicksearchbox/). Really there's no motive to subvert the order of things and promote web search over OS search in a OS search app unless you own a search engine like Google.
Which isn't to say it (and Music) shouldn't be updated, since they do serve as docs for 3rd party devs and OEMs, so not updating would have some indirect inverse effect on the quality of apps. But I can see why they haven't got around to it yet given their trajectory.
tl;dr the situation is more grey than black or white.
An alternative would be to use GSM as a shim, that just calls through to AOSP if the functionality is there, or fills in the functionality if it's not.
But I'm not seeing the advantage to Google of doing that - as everyone gets GSM if they go for the major phones.
But I'm not seeing the advantage to Google of doing that - as everyone gets GSM if they go for the major phones.
There is one factor that causes what's going into GMS and what into AOSP, that the article conveniently glosses over:
Functionality in GMS requries server side support. It can be computational capacity or server-side dabatases (fused location with wifi and cell towers? Google caller id? Map tiles? Storage? Server side push? Cloud support for games? All of them require something on the other side of connection).
Unless someone is willing to step in and provide this, there will be no AOSP equivalent.
Functionality in GMS requries server side support. It can be computational capacity or server-side dabatases (fused location with wifi and cell towers? Google caller id? Map tiles? Storage? Server side push? Cloud support for games? All of them require something on the other side of connection).
Unless someone is willing to step in and provide this, there will be no AOSP equivalent.
>Functionality in GMS requries server side support.
Really? My calendar client, mail client, and launcher require server side support from Google?
Really? My calendar client, mail client, and launcher require server side support from Google?
Launcher certainly does - where do you think that Google Now prepares it's data?
Launcher without Google Now is part of AOSP.
Both Calendar and Email are available in AOSP, Play Store has their binary builds for those that for some reason do not have current Android version. They can have at least current apps.
Launcher without Google Now is part of AOSP.
Both Calendar and Email are available in AOSP, Play Store has their binary builds for those that for some reason do not have current Android version. They can have at least current apps.
They could have made google now a plugin.
Calendar and email in AOSP suck.
Calendar and email in AOSP suck.
Most GSM APIs are based around Google services and products, so some of the APIs don't really have an equivalent in AOSP. One of the other reasons why Google likes GSM over AOSP is the fact that there is much better control over versions of code out in the wild, whereas AOSP rollouts that come with updates to the phone propagate more slowly and inconsistently.
Google could just add a clause in their manufacturer MOU and kill fragmentation easily. Moving the functionality into apps is an unnecessary extreme.
Amazon has obviously forked Android successfully and has sold a lot of tablets. OPhone is an Android derived OS used in China, and other Chinese OEMs without access to the Google ecosystem have to do similar things.
Amazon is a special case. They don't care about compatibility, since they're building a very focused, special-purpose platform of their own. Like the original iPhone, the Kindle is attractive enough that people will buy it without any apps. Android was just a way for them to cut their time-to-market.
Microsoft has a different set of problems. Windows Phone is already shipping, so adopting Android would actually delay the next release. What they need is a stronger ecosystem—more apps to bring users and more users to bring developers. Adopting Android might help them achieve that, but at the cost of ceding control to Google. At the end of the day, why would anyone buy Android from Microsoft instead of Google?
If they can't make a success of Windows Phone, MS would be better off to just can it and provide apps and services to both iOS and Android.
Microsoft has a different set of problems. Windows Phone is already shipping, so adopting Android would actually delay the next release. What they need is a stronger ecosystem—more apps to bring users and more users to bring developers. Adopting Android might help them achieve that, but at the cost of ceding control to Google. At the end of the day, why would anyone buy Android from Microsoft instead of Google?
If they can't make a success of Windows Phone, MS would be better off to just can it and provide apps and services to both iOS and Android.
The Kindle Fire is actually quite compatible, though. The launcher/core experience is very different, but the app selection is basically identical. GMS has some nice APIs, but the truth is that most apps (by download count, or by revenue) either don't use them or can configure them out.
The kindle isn't successful because Amazon was able to eject compatibility concerns, it's successful because Amazon was (unlike basically all the other variant Android customizations) able to bring elements to the platform that customers actually wanted, and that these outweighed their desire for interoperability with the Google GMS ecosystem.
The kindle isn't successful because Amazon was able to eject compatibility concerns, it's successful because Amazon was (unlike basically all the other variant Android customizations) able to bring elements to the platform that customers actually wanted, and that these outweighed their desire for interoperability with the Google GMS ecosystem.
According to a recent email I got from Amazon App Distribution: "75% of the Android tablet apps tested by Amazon already work on Kindle Fire without any extra development."
"If they can't make a success of Windows Phone, MS would be better off to just can it and provide apps and services to both iOS and Android"
That was true until the moment they spent $7.2 billion acquiring a company and 30,000 employees that need to make (and sell) devices to keep going.
MSFT now has an interest in shipping hardware that will compete with their software interests.
That was true until the moment they spent $7.2 billion acquiring a company and 30,000 employees that need to make (and sell) devices to keep going.
MSFT now has an interest in shipping hardware that will compete with their software interests.
Another fork of Android that makes sense is Firefox OS. They take the Android kernel and drivers to get hardware compatibility, and layer a new set of APIs and apps on top of it. They don't care about compatibility, because they're interested in promoting web technologies rather than selling hardware, promoting services or making money from licensing.
I wouldn't exactly call Firefox OS an Android fork. Android is more than just the Linux kernel, it's also Dalvik and a large set of Java APIs. From an app developer perspective, the language and APIs matter much more than the kernel; Firefox OS is completely different from Android in this regard.
I thought Gonk took bits from Android, but was not a direct copy of the kernel.
Microsoft has OS problems.
Windows CE was un-competitive with Linux, so they had to go to an NT-derived kernel and "real Windows" userland elements for the core OS. But those are bloaty and suck batteries and need fast CPUs.
I don't think they should exactly adopt Android, but they should, at least, have considered doing something Android-like. Imagine the .NET runtime on Linux. That would be very Android-like, but compatible with .NET languages and the VS toolchain.
Windows CE was un-competitive with Linux, so they had to go to an NT-derived kernel and "real Windows" userland elements for the core OS. But those are bloaty and suck batteries and need fast CPUs.
I don't think they should exactly adopt Android, but they should, at least, have considered doing something Android-like. Imagine the .NET runtime on Linux. That would be very Android-like, but compatible with .NET languages and the VS toolchain.
I own an Amazon Kindle Fire. It sucks. Out of the box it can do almost nothing that normal android devices can. I had to root it in a very frustrating and glitchy process to be able to install google app store software and even of that many don't install or don't work.
What amazon has successfully done is build a kindle based on linux as opposed to whatever is on the original kindles. It's a very limited thing and nothing more than a kiosk to amazon purchases.
The only reason people buy it is because of brand loyalty to the kindle device series they knew before.
What amazon has successfully done is build a kindle based on linux as opposed to whatever is on the original kindles. It's a very limited thing and nothing more than a kiosk to amazon purchases.
The only reason people buy it is because of brand loyalty to the kindle device series they knew before.
> I had to root it in a very frustrating and glitchy process to be able to install google app store software and even of that many don't install or don't work.
The root process for Kindle devices is very annoying. However, there is a reason why most app store apps don't work on Kindle. Unless a developer is specifically thinking about supporting a device without Google APIs, they are likely not to correctly handle when API calls fail or aren't available. Also, the Kindle Fires to date have had some quirks here and there that don't work exactly as you would expect, so a developer would probably have to actually test their app for Kindle (which is its own pain due to how bad the Amazon developer portal is).
The root process for Kindle devices is very annoying. However, there is a reason why most app store apps don't work on Kindle. Unless a developer is specifically thinking about supporting a device without Google APIs, they are likely not to correctly handle when API calls fail or aren't available. Also, the Kindle Fires to date have had some quirks here and there that don't work exactly as you would expect, so a developer would probably have to actually test their app for Kindle (which is its own pain due to how bad the Amazon developer portal is).
The original Kindles, afaik, were based on Linux, with I guess a custom stack on top.
Yep, the kernel sources are available on the Amazon website: http://www.amazon.com/gp/help/customer/display.html?nodeId=2...
the article author does not know what eff they are speaking about:
The AOSP counterparts are buggy, feature deprived, and by at least some accounts, barely maintained.
If that sentence was true than stuff like the phone app would not work, obviously it does :)
Author does not realize that AOSP is a snapshot of the full android OS
If that sentence was true than stuff like the phone app would not work, obviously it does :)
Author does not realize that AOSP is a snapshot of the full android OS
The author mentions "you can have control or compatibility, but not both". That's basically another way or saying "you can fragment the platform all you want, or choose compatibility (i.e. let Google control the platform across OEMs)". Remember when people were yelling from the rooftops "Android is so fragmented, and why it's always behind iOS! Google, give us standardization already!!"?
Linux' biggest problem has been that Microsoft moved much faster to get Windows on as many PCs as possible through certain corporate deals, but in terms of gaining market share, the Linux ecosystem has also worked against itself, but allowing everyone to fork it into hundreds of different distributions, all doing different stuff, and with barely even a weak app store across several distributions.
Linux is "everywhere", because everyone can fork it, and Android has certainly benefited from this strategy in the early years, too, but that seems to be an antithesis to an "ecosystem". As we can observe, even though "Linux is everywhere" in all sorts of devices, there's no significant "ecosystem".
Google wants to keep and evolve the Android ecosystem, because that makes it much easier for users, and also developers to develop on top of a well standardized ecosystem of devices and OS images. I guess for an proper ecosystem to thrive, it needs to be controlled and standardized as much as possible, with restrictions for OEMs and carriers.
The only alternative for the others, if they really want to start from the Android base, will be to form their own ecosystem, but that's very hard, unless we get to the point where only the web matters on mobile devices, too.
Linux' biggest problem has been that Microsoft moved much faster to get Windows on as many PCs as possible through certain corporate deals, but in terms of gaining market share, the Linux ecosystem has also worked against itself, but allowing everyone to fork it into hundreds of different distributions, all doing different stuff, and with barely even a weak app store across several distributions.
Linux is "everywhere", because everyone can fork it, and Android has certainly benefited from this strategy in the early years, too, but that seems to be an antithesis to an "ecosystem". As we can observe, even though "Linux is everywhere" in all sorts of devices, there's no significant "ecosystem".
Google wants to keep and evolve the Android ecosystem, because that makes it much easier for users, and also developers to develop on top of a well standardized ecosystem of devices and OS images. I guess for an proper ecosystem to thrive, it needs to be controlled and standardized as much as possible, with restrictions for OEMs and carriers.
The only alternative for the others, if they really want to start from the Android base, will be to form their own ecosystem, but that's very hard, unless we get to the point where only the web matters on mobile devices, too.
> The author mentions "you can have control or compatibility, but not both".
Or you can be like Apple, controlling everything while still taking the liberty of shitting down developer's throats (who are delighted to be at the receiving end, for some reason).
Or you can be like Apple, controlling everything while still taking the liberty of shitting down developer's throats (who are delighted to be at the receiving end, for some reason).
It's not a poor idea at all. The main example used to be Amazon, but now it's China. China are going to be the source of a lot of Google headaches, thanks to their inability to operate there leading to a majority of Android devices shipped there not including their services at all, giving a critical mass to the market for applications without their components.
Hugo Barra ended up at a Chinese company (Xiaomi) and Google just invested in Lenovo, but unless there's a big policy change on the way the Android/China beast will get further and further out of control.
MS absolutely should weigh in with a privacy hardened Android with great Exchange and Active Directory support (and Nokia Maps). It would be huge, and it would force Apple and Google right on to the defensive.
Hugo Barra ended up at a Chinese company (Xiaomi) and Google just invested in Lenovo, but unless there's a big policy change on the way the Android/China beast will get further and further out of control.
MS absolutely should weigh in with a privacy hardened Android with great Exchange and Active Directory support (and Nokia Maps). It would be huge, and it would force Apple and Google right on to the defensive.
But it would have lousy app compatibility... so what advantage would it offer over Windows Phone?
It would have about as lousy app compat as the Kindle Fire, which is to say nothing like as much as Google would like you to believe.
I'll say it: the Amazon APIs are actually better than some of the Google equivalents too. MS can play exactly the same game, but with the muscle of small business users.
Windows Phone simply has negligible actual interest from the dev community because it's too much of a technical island, and tied to the whole Metro disaster.
I'll say it: the Amazon APIs are actually better than some of the Google equivalents too. MS can play exactly the same game, but with the muscle of small business users.
Windows Phone simply has negligible actual interest from the dev community because it's too much of a technical island, and tied to the whole Metro disaster.
It would have better app compatibility than Windows Phone.
I don't get why this censoring, which stop US businesses like Google, doesn't lead to a trade war? The Americans are usually not shy about those?
Edit: fidotron, to me it seemed China tried to get rid of Google (internal hacking attacks, etc). That level of aggression is normal for China?
Edit: fidotron, to me it seemed China tried to get rid of Google (internal hacking attacks, etc). That level of aggression is normal for China?
Because it's self censorship on Google's part.
The killer problem, from a western dev perspective, is you can only distribute free apps on the Play Store in China since Google don't process payments there. Their ad systems also do not work. Apple do not have these problems, largely since their surface area around problematic services is so much smaller.
Google are in a bit of a spot here, especially post Snowden basically showing the western govs were no worse than the Chinese (at least at monitoring, though maybe not in consequences of those being monitored) when the aggressive surveillance by the Chinese was stated as the reason for their withdrawal. It still amazes me how naive Googlers seem to be about issues with surveillance and security in general in a political sense, not merely a technical one.
The killer problem, from a western dev perspective, is you can only distribute free apps on the Play Store in China since Google don't process payments there. Their ad systems also do not work. Apple do not have these problems, largely since their surface area around problematic services is so much smaller.
Google are in a bit of a spot here, especially post Snowden basically showing the western govs were no worse than the Chinese (at least at monitoring, though maybe not in consequences of those being monitored) when the aggressive surveillance by the Chinese was stated as the reason for their withdrawal. It still amazes me how naive Googlers seem to be about issues with surveillance and security in general in a political sense, not merely a technical one.
China isn't guilty only about surveillance, but also about censorship - which is the reason for Google's actions, that were probably made because of both moral and technical issues - since it is difficult to censor stuff at Google's scale.
And in so far as the western governments being no worse than the Chinese - what a bunch of crap.
And in so far as the western governments being no worse than the Chinese - what a bunch of crap.
Many companies produce Android devices without google maps, gmail, play store... It solves a lot of privacy issues.
In 5 years smartphones will be cheap commodity and there will be also good opensource community fork. I can see Debian on Android.
In 5 years smartphones will be cheap commodity and there will be also good opensource community fork. I can see Debian on Android.
Five years? You can buy smart phones for 30$ in shenzhen electronic malls today. I don't know your threshold for cheap, but considering feature phones sit at 25 to 20 in the same places.. The future is now :-)
>>>You can buy smart phones for 30$ in shenzhen electronic malls today.
1) That's in Shenzen. Might as well be Mars for most people. When Shenzen hardware is sourced by global brands, they usually have a generous markup where that "$30" quickly disappears.
2) How long do they last? "Oh, but they're cheap. If it breaks in 3 months, just buy another!" No. People just don't want to go through possibly losing data and having hardware just suddenly drop dead on them.
So, yeah. I'll go with the guy who said five years. That's for stuff that won't drop dead in three months.
1) That's in Shenzen. Might as well be Mars for most people. When Shenzen hardware is sourced by global brands, they usually have a generous markup where that "$30" quickly disappears.
2) How long do they last? "Oh, but they're cheap. If it breaks in 3 months, just buy another!" No. People just don't want to go through possibly losing data and having hardware just suddenly drop dead on them.
So, yeah. I'll go with the guy who said five years. That's for stuff that won't drop dead in three months.
> That's in Shenzen. Might as well be Mars for most people.
Ah, yes, if only some smart people could invent some kind of global network for people to buy things remotely, and created some site where you could order these things. They could call it, for example, Ali Baba.
Ah, yes, if only some smart people could invent some kind of global network for people to buy things remotely, and created some site where you could order these things. They could call it, for example, Ali Baba.
Still Mars. Unknown companies, unknown quality, unknown warranties (as in mostly non-existent). And sending it back to China to exchange a defective unit? Suddenly that $30 isn't.
A wide range of these products are available at reasonable markups via a variety of Amazon Marketplace resellers.
That's how I got my first one. But since then I've started ordering direct from Alibaba/Aliexpress and for many products the savings are large enough to "self insure" and still be worth it with a good margin.
That's how I got my first one. But since then I've started ordering direct from Alibaba/Aliexpress and for many products the savings are large enough to "self insure" and still be worth it with a good margin.
$30 is cheap enough for most people that they wouldn't expect warranties and excellent build quality.
Have a link?
http://www.alibaba.com/wholesale/categories/Mobile-Phones_50...
or
http://www.aliexpress.com/category/5090301/mobile-phones.htm...
depending on the quantities you would like to purchase
or
http://www.aliexpress.com/category/5090301/mobile-phones.htm...
depending on the quantities you would like to purchase
Go up to ~$100 and the choice of smartphones becomes even more diverse. Quality would probably be a bit better too. This is with no contract, unlocked everything (chances are it's also Mediatek based, which means no bootloader locking AFAIK), and you get all the features like dual SIM, removable battery and expandable storage that most of the big-name manufacturers don't want you to have.
Edit: actually, it looks like $50 is already enough to get a pretty good entry-level Android phone; look up the Jiayu F1.
Edit: actually, it looks like $50 is already enough to get a pretty good entry-level Android phone; look up the Jiayu F1.
Microsoft could build a fully functional Mono-based Windows Phone experience on top of the AOSP core minus the Dalvik VM.
The only question would be "what for"? They'd gain nothing from it. They already have a more or less portable kernel upon which they can build phones.
The only question would be "what for"? They'd gain nothing from it. They already have a more or less portable kernel upon which they can build phones.
It sounds to me like what they need is exactly the other way around: Dalvik VM + all the Java APIs in Android, on top of the WP kernel (or they could go with Linux, but I think the kernel doesn't matter as much).
This.
But there is one problem with that strategy: if Microsoft would support running Android apps on Windows Phone, there would be little incentive left to write native WP apps. Everybody would only write for Android, making it hard to differentiate the platform.
But there is one problem with that strategy: if Microsoft would support running Android apps on Windows Phone, there would be little incentive left to write native WP apps. Everybody would only write for Android, making it hard to differentiate the platform.
I wonder if it would be feasible to support Java and maybe some (most? some well-defined base of?) Android APIs in "native" Windows apps, in a similar way to how JavaScript and HTML are supported via WinRT's notion of language projections. Although this would mean narrowing the goal from "making Android apps run on Windows" to "making Android apps easier to port to and maintain on Windows".
Besides, since the Visual 2013 launch event, Xamarin has become an official Microsoft partner.
This piece seems to imply that only full source compatibility with Android (including Play Services) would be valuable to the Windows Phone platform. I don't think that's the case. I think getting 80% of the way, combined with the Microsoft brand plus quality devices Nokia would be enough to entice plenty of developers to the platform.
I think a more interesting question is whether Microsoft should fork AOSP as a whole, or place an Android compatibility layer atop Windows Phone, a la BlackBerry 10.
I think a more interesting question is whether Microsoft should fork AOSP as a whole, or place an Android compatibility layer atop Windows Phone, a la BlackBerry 10.
Didn't Google won the the "Oracle vs Google" case on the ground that APIs aren't patentable?
What prevent MS(or any other big player) to re-implement GMS?
What prevent MS(or any other big player) to re-implement GMS?
The "Oracle vs Google" case isn't over, it's up for appeal...
It would be funny if Google copied Microsoft's monopolist strategies to avoid Windows cloning (APIs are ever changing and complex, especially regarding bug compatibility, no protocol docs+obfuscation, etc)... :-)
[deleted]
The title is a bit of a linkbait for sure. I don't think anyone at this point can say that Windows Phone is a non-player. It's going to be around and it can only get better.
Suggesting that Microsoft would fork Android is more wishful thinking than anything else.
Why not just say - "Android is unforkable" and leave it at that.
Suggesting that Microsoft would fork Android is more wishful thinking than anything else.
Why not just say - "Android is unforkable" and leave it at that.
From http://www.theguardian.com/technology/2014/feb/07/satya-nade... , which is linked at the beginning of the article:
"To add to all the advice being ladled out to Satya Nadella, Microsoft’s new chief, here’s another piece: stop bothering with Windows Phone. It’s a waste of money which will never pay off.
Instead, focus the efforts of Microsoft and soon-to-be subsidiary Nokia on forking Android .."
So at least someone with an audience is saying that MS should fork Android, and Ars is responding to that.
"To add to all the advice being ladled out to Satya Nadella, Microsoft’s new chief, here’s another piece: stop bothering with Windows Phone. It’s a waste of money which will never pay off.
Instead, focus the efforts of Microsoft and soon-to-be subsidiary Nokia on forking Android .."
So at least someone with an audience is saying that MS should fork Android, and Ars is responding to that.
People with an audience say all kinds of idiotic things. Arguing that Microsoft should fork another OS is like saying that Ford should license the Toyota Prius design and concentrate on their core competency of putting Ford badges on cars.
> Why not just say - "Android is unforkable" and leave it at that.
Because that's the most ridiculous part. Amazon already did it. Microsoft's own mobile division is in the process of doing it themselves! Others have also done it. To say that something so many people have actually done is undoable is a little bit crazy.
Because that's the most ridiculous part. Amazon already did it. Microsoft's own mobile division is in the process of doing it themselves! Others have also done it. To say that something so many people have actually done is undoable is a little bit crazy.
>"I don't think anyone at this point can say that Windows Phone is a non-player."
I wouldn't be so sure of that. Just this week I read a comment suggesting the same forking android thing and that windows phone is over.
I wouldn't be so sure of that. Just this week I read a comment suggesting the same forking android thing and that windows phone is over.
Would you like me to write a comment suggesting that Apple is opting for using Windows for their products? I can write some other comments as well.
Well since that is a comment that pop up in here very frequently (that Nokia and now MS should fork Android) I am very happy to see that I am not the only one who thinks that would be a bad idea.
"typed on my Kindle Fire"
Interesting analysis but I think he overcomplicates the situation.
From a third party app point of view you can build your against Android API level X, or a corresponding ‘Google api’ release associated with the given API level. An app built against API level X will work seamlessly on the corresponding AOSP release.
So far, unless you’re interested in more tightly integrating into Google services, you don’t need to build your app against the Google api, but obviously Google are interested in app developers using their custom apis.
As far as the increasing integration of core applications into GMS is concerned, it is rather overblown to call the AOSP versions broken or buggy. AOSP remains the base platform for the hardware ecosystem to develop their reference designs, AOSP has to work and does work well.
The hardware domain is a big problem for rolling your own OS from scratch, the associated software stack to support a given piece of hardware is non-trivial. Even generic Linux is now being supplanted by Android variants in the embedded space especially if you’re interested in graphics or multimedia.
However, also consider that the most successful player in the Android space, Samsung, have pursued a strategy of lightly forking Android with their own features and customizations without breaking compatibility deliberately.
From a third party app point of view you can build your against Android API level X, or a corresponding ‘Google api’ release associated with the given API level. An app built against API level X will work seamlessly on the corresponding AOSP release.
So far, unless you’re interested in more tightly integrating into Google services, you don’t need to build your app against the Google api, but obviously Google are interested in app developers using their custom apis.
As far as the increasing integration of core applications into GMS is concerned, it is rather overblown to call the AOSP versions broken or buggy. AOSP remains the base platform for the hardware ecosystem to develop their reference designs, AOSP has to work and does work well.
The hardware domain is a big problem for rolling your own OS from scratch, the associated software stack to support a given piece of hardware is non-trivial. Even generic Linux is now being supplanted by Android variants in the embedded space especially if you’re interested in graphics or multimedia.
However, also consider that the most successful player in the Android space, Samsung, have pursued a strategy of lightly forking Android with their own features and customizations without breaking compatibility deliberately.
The guy that ran windows phone is now the head of the entire windows division. His name is Terry Myerson. I doubt very seriously that he is going to shitcan windows phone.
Windows Phone is already shit canned. MS just isn't smart enough to get it.
Quick, give us more of your amazing market insight!
Sure, no problem. Windows Phone will be cancelled in 2015 after MS realizes it's been a massive failure. They'll also lay off 30,000-40,000 people in 2014. And they'll quietly sell off the device division they bought for 7 Billion dollars and take a massive loss.
I think that you missed my point. The guys that was in charge of developing Windows Phone 8 is now the guy in charge of Windows. Windows Phone won't be canceled, it and Windows will become the same thing...just with form factor differences. Same thing with XBOX OS. It's Windows. Things that make sense for the desktop won't be on the XBOX or the Phone...and vice versa. You sound like you aren't a metro fan...They do need to make sure that the desktop is still a useful tool...but here's the thing. In 5 years you will be hard pressed to find a monitor of any size or type that isn't touch enabled.
As to selling off the device division...I don't see that happening either. MS needed Nokia's supply chain, and delivery systems. They needed to have a division that knows how to take a device from the drawing board to the shelf quickly...which Nokia should be able to do now that it doesn't have to make money. It's weird, but taking a long term view with the device department just like bing and xbox gives the people in that org some room to move.
I find it crazy how much people dislike one company while another company...also a legal fiction that exists solely to make money...that company is ok. They "get" me...or "it". Like Google's PR moves like "solving death"? Seriously? They sell advertising. Meaning that they sell YOU. I"m under no illusions about MS prior behavior. I'm also under no illusions that Apple or Google are somehow different. They aren't.
As to selling off the device division...I don't see that happening either. MS needed Nokia's supply chain, and delivery systems. They needed to have a division that knows how to take a device from the drawing board to the shelf quickly...which Nokia should be able to do now that it doesn't have to make money. It's weird, but taking a long term view with the device department just like bing and xbox gives the people in that org some room to move.
I find it crazy how much people dislike one company while another company...also a legal fiction that exists solely to make money...that company is ok. They "get" me...or "it". Like Google's PR moves like "solving death"? Seriously? They sell advertising. Meaning that they sell YOU. I"m under no illusions about MS prior behavior. I'm also under no illusions that Apple or Google are somehow different. They aren't.
Android is already forked[1].
Gingerbread: 20%
Ice Cream Sandwich: 16%
Jelly Bean: 60%
KitKat: 2%
Not forked, fragmented.
I want to like the article, because the idea that Microsoft should fork Android is kinda silly. The idea that nobody should do it is even sillier, though.
The article, in the course of explaining why it can't be done, names two major examples of where it already has been done successfully -- Amazon's Kindle ecosystem and any number of Chinese OEMs. It doesn't mention other (admittedly less successful) forks, like B&N's Nook tablets or the Ouya. It also doesn't mention how far along the road Samsung was to having the ability to ship Android without Google Mobile Services, until Samsung and Google made a peace treaty that involved sending Motorola off to live with Lenovo.
Yes, if you fork Android, you lose Google's ecosystem. It's not impossible to duplicate, though -- Amazon's done it, Samsung just about did it. And Microsoft already owns all the things it'd need to do it -- that's how Windows Phone has an ecosystem. Losing Google's ecosystem isn't the downside of forking Android, it's the entire point.
Once you've done it, though, you need to convince people to use your fork instead of Google's. Microsoft's success at prying people towards Windows Phone and away from Android can basically boil down to:
1) The ability to run on lower-powered and thus cheaper hardware and still provide a polished experience, and 2) Nokia's build quality.
Switching OS cores to AOSP instead of the current Windows Phone OS wouldn't entirely solve Microsoft's app problem (look at the Amazon app store), and it would piss away the only competitive advantage their platform (as opposed to their OEM partner) has against Google's Android experience. Microsoft isn't Amazon -- they aren't a cloud company looking for an OS to give to consumers, they already have an OS. They just need to make their ecosystem more appealing, and giving up on Windows Phone now wouldn't do that.
The article, in the course of explaining why it can't be done, names two major examples of where it already has been done successfully -- Amazon's Kindle ecosystem and any number of Chinese OEMs. It doesn't mention other (admittedly less successful) forks, like B&N's Nook tablets or the Ouya. It also doesn't mention how far along the road Samsung was to having the ability to ship Android without Google Mobile Services, until Samsung and Google made a peace treaty that involved sending Motorola off to live with Lenovo.
Yes, if you fork Android, you lose Google's ecosystem. It's not impossible to duplicate, though -- Amazon's done it, Samsung just about did it. And Microsoft already owns all the things it'd need to do it -- that's how Windows Phone has an ecosystem. Losing Google's ecosystem isn't the downside of forking Android, it's the entire point.
Once you've done it, though, you need to convince people to use your fork instead of Google's. Microsoft's success at prying people towards Windows Phone and away from Android can basically boil down to:
1) The ability to run on lower-powered and thus cheaper hardware and still provide a polished experience, and 2) Nokia's build quality.
Switching OS cores to AOSP instead of the current Windows Phone OS wouldn't entirely solve Microsoft's app problem (look at the Amazon app store), and it would piss away the only competitive advantage their platform (as opposed to their OEM partner) has against Google's Android experience. Microsoft isn't Amazon -- they aren't a cloud company looking for an OS to give to consumers, they already have an OS. They just need to make their ecosystem more appealing, and giving up on Windows Phone now wouldn't do that.
> 1) The ability to run on lower-powered and thus cheaper hardware and still provide a polished experience, and 2) Nokia's build quality.
The Moto G has put a price floor on things. Even if Microsoft/Nokia could limbo under it, why would anybody buy a basically-the-same Nokia for $150 instead of $179 Real Android? Its too late, these are commodities.
The Moto G has put a price floor on things. Even if Microsoft/Nokia could limbo under it, why would anybody buy a basically-the-same Nokia for $150 instead of $179 Real Android? Its too late, these are commodities.
When you're dealing with budget phones, you're talking about super price sensitive buyers. The 520 goes for what, $70 or so? And it's actually a good experience, and a nice phone for that money. Sure, the Moto G is at least 2X better, but with the consumers we're talking about here, that doesn't matter. It's a fascinating area to watch!
You can get a Nokia 520/521 for a little over a third of $150.
From its wiki page:
"The price was halved to $50 (£70 in the UK) for the holidays"
So its $100 and only roughly comparable. And that's rather my point, few people from developed countries will opt for it to save $79.
So its $100 and only roughly comparable. And that's rather my point, few people from developed countries will opt for it to save $79.
From "developed" countries? No. From countries with subsidized handsets, maybe. But Europe is certainly "developed," and that's where Windows Phone is making its biggest inroads:
http://www.zdnet.com/windows-phone-takes-more-of-europes-sma...
http://www.zdnet.com/windows-phone-takes-more-of-europes-sma...
"They just need to make their ecosystem more appealing"
You say "just" but that is literally the hardest thing to do. They've been trying very, very hard to make their ecosystem more appealing with tremendous amounts of money and manpower.
You say "just" but that is literally the hardest thing to do. They've been trying very, very hard to make their ecosystem more appealing with tremendous amounts of money and manpower.
Sure, but that problem doesn't go away if they switch to using AOSP.
> It also doesn't mention how far along the road Samsung was to having the ability to ship Android without Google Mobile Services, until Samsung and Google made a peace treaty that involved sending Motorola off to live with Lenovo.
Do you have a source on that? When I think about it seems logical but it never occoured to me that Google could have been "forced" into leaving motorola. Clearly any sane exec would choose Samsung having google apps over mororola under different owner. But I would like to know where you got the idea from.
Do you have a source on that? When I think about it seems logical but it never occoured to me that Google could have been "forced" into leaving motorola. Clearly any sane exec would choose Samsung having google apps over mororola under different owner. But I would like to know where you got the idea from.
Here you go:
http://arstechnica.com/gadgets/2014/01/nuclear-stand-down-go...
The most germane part to the author's premise is the graphic that illustrates how Samsung has apps to duplicate pretty much every app Google has. (With, admittedly, the very notable exception of Maps. Even Apple has had a rough time of getting away from Google Maps, I think that'd be a very difficult piece for Samsung without going to Nokia for help.)
http://arstechnica.com/gadgets/2014/01/nuclear-stand-down-go...
The most germane part to the author's premise is the graphic that illustrates how Samsung has apps to duplicate pretty much every app Google has. (With, admittedly, the very notable exception of Maps. Even Apple has had a rough time of getting away from Google Maps, I think that'd be a very difficult piece for Samsung without going to Nokia for help.)
Just about the smartest thing Microsoft could do is port Windows to run on the Android/Linux kernel.
Ironically, they would buy themselves a tremendous amount of hardware support that way. They'd lose very little in the process. The Windows kernel is pretty decrepit.
Ironically, they would buy themselves a tremendous amount of hardware support that way. They'd lose very little in the process. The Windows kernel is pretty decrepit.
As the developer of a couple of small Android apps, I know that I would rather post them to a Microsoft or Nokia Android app store than port them to Windows Phone. Of course, it helps that I specifically avoided using the Google Play Services APIs, but even if I had used those APIs, it would be easier to make my apps Google-independent than to port them to a whole other platform with miniscule market share.
What do they mean unforkable? Cyanogen Mod[1] has been doing it for years.
[1]: http://www.cyanogenmod.org/
[1]: http://www.cyanogenmod.org/
Amazon also did it.
Cyanogen Mod cheats by backing up GMS prior to install.
Look at the closed source services google adds. As far as I know they are all related to google services(Someone please correct me if I'm wrong). Their store, their maps, their email, their location services. This isn't needed in the open source distro and it works great without them. Also there are a lot of restriction on the brand and how you use it when release an Android product. That isn't unique to Android. See firefox vs iceweasel.
Sure sometimes it gets annoying that a lot of Android design decisions are made behind closed doors and in working in the framework sometimes I have to play the game of "Guess what the Google engineer was thinking" because documentation can be scarce. Also from what I've heard sending changing upstream isn't an easy process. These things are nice and make it an easy product to work with... but aren't required for it to be truly open source. The code is there in a series of open git repos and under Apache license. That is open source in my book.