Google's (or is it Intel) got to be out of decent QA people. The 64 bit image doesn't even start on Linux and the G+ post has people complaining the same about Windows and OS X.
As does the new Tesco* Hudl2 tablet, against ARM in the outgoing v1.
Released this week, if it follows is predecessor it will quietly sell a million units in the UK and never even register on the radar of most Android tech blogs.
* a big supermarket chain in UK & Europe, which also tried to venture farther east.
You aren't necessarily saying differently, but it's worth noting that Android has supported x86 for quite some time (the platform, the runtime, the NDK cross-compiling, and the x86 emulator image -- all have been available for a couple of years).
And to the other comment (from a different user, though I am responding here while on the topic of x86) claiming that Intel support doesn't matter -- it very much matters. Already there are a large number of deployed x86 devices (even ones that people don't realize are x86, like the Dell Venue 7), and Broadwell will only accelerate that. Supporting multiple platforms is awesome.
Eh, Java only Android apps have run fine on x86 Android devices for years. There's a consumer x86 tablet out there I've run stuff on - won one of the tablets at a hackathon in NYC last year for getting a WebRTC client running on it.
Heck, even native ARM lib stuff is supposed to run fine, but slow, due to some some special libhoudini translation layer Intel made to handle it.
Is the source code for the emulator available? L maybe not ready, but is the kitkat x86 emulator source code part of the AOSP where I can build completely from src?
Are you talking about micro-consoles? Why would they be better with Atom over something like Tegra K1? (which the first Android TV box is said to have anyway).
Intel has given up on TV's a long time ago - around the time it forced Logitech to launch the first Google TV for $300 because Atom was like $90 a piece, as a component (probably making for about 50 percent of its BOM).
Sure, the Atom vs K1 comparison isn't necessarily in favor of Intel, but the comment you are replying to didn't mention Atom. I would argue that gaming consoles (micro or not) do make more sense with a X86 processor than what is available in ARM space currently. Think Intel i5 or AMD's APUs though, not Atom.
While there is a huge benefit in running as much computation as possible out of the CPU and on more specialized chips, the two leading high end consoles use x86 CPUs to run a fairly large part of the overall processing. ARM is no magic and its price advantage came mostly from being simple and good enough at a time even the lowest end x86 would be overkill. Today there are some very low power x86 solutions that can compete with ARM solutions in both price and processing/watt.
Samsung already has a 64-bit ARM chip in Note 4. But because Google seems to be dragging its feet on adding 64-bit ARM support, it only works in 32-bit mode for now.
HTC has also just launched not one, but two, 64-bit devices: Desire 510 and Desire 820, with Snapdragon 410 and 615 - both based on Cortex A53 (ARMv8).
So the question is, why is Google so slow with 64-bit ARM support, when 64-bit ARM Android devices are already shipping?
Why 64bit is needed in phones right now?
Is there a memory limit similar to he one on PCs where 32bit can support up to 4GB RAM?
If so then I think there aren't many phones that have 3GB, not to mention 4GB.
ARMv8 has more registers in addition to 64-bit address space support, so almost all applications should benefit from the minimization of register spilling.
Anybody using Android L? I've been using it on my primary phone for a month and I'm not impressed. It freezes too often needing a reboot, Hangouts Dialer often cannot complete or receive calls, the screen lock is buggy requiring a workaround how to get in without having to reboot, the bright theme is a step back when a dark one is not available. Many basic apps don't work or misbehave (Swarm, Square Cash, etc.). Worst of all, there are no frequent updates (if any), no autoupdate either.
> Worst of all, there are no frequent updates (if any), no autoupdate either.
Is a little odd. Didn't you install the L developer preview by manually downloading the ROM from here: https://developer.android.com/preview/setup-sdk.html and then flashing it yourself? Then you're strangely shocked there isn't a consumer-orientated auto-updater?
I can absolutely see that criticism if the auto-updater didn't exist, wasn't working, or there were no updates upon the retail release of L. For a developer preview you personally installed knowing full well it was a developer preview that criticism is hard to take at all seriously.
Apple's been supporting this for the last couple years. This year, for instance, I upgraded to iOS 8 when Beta 3 shipped. I then received OTA updates for each subsequent Beta until the final release, which I installed manually. It's unfortunate that Google doesn't offer OTA beta updates, too.
Well, that's fine, but then Google failed. Delivering some dated and possibly insecure copy is not how everybody else does it in 2014. There are high standards for prelease software today - other Google projects follow them, so, Android shouldn't be an exception.
This is the first time they're offering a peek into a pre-release of their OS, ever. Apple has done multiple times with a track record of auto-updates, so yes, that can be expected of Apple, and Apple only.
Google never promised updates, never promised stability, it's not a beta, it's not a GM, it's not even alpha. It's simply a preview. You get what they say you get. Don't set iOS's standards on Android, they're completely different products, with completely different cultures, release cycles, everything.
There are a lot of products, Google and otherwise, that go straight to release without any prereleases. If anything Android has has a very strict record of that, so I think your expectations of much more from them on such a large release like L is simply unfounded.
So, because it's first time, but in contrast with their other teams and with other companies, I should be satisfied? You guys are a bunch of low-standards fanboys, especially those who take pleasure in downvoting every single comment I made here as a punitive action against daring to state the obvious. Android prerelease process should improve, I'm not satisfied and I don't care that some people are okay with everything and don't bother to demand more! Even Play Store now has the concept of prelease software that autoupdates! And they have a completely separate static build for Android Fit. Just ridiculous!
> You guys are a bunch of low-standards fanboys, especially those who take pleasure in downvoting every single comment I made here as a punitive action against daring to state the obvious
It's more the terrible quality of your posting. You've been given reasonable answers but instead you respond with demands you have no position to be making.
"Reasonabe" according to a low-standards crowd. I'm a different breed. I demand high-standards from myself and others. There's a fierce competition today, if you haven't noticed. And Google lags behind.
Apple iOS prereleases support more devices than Android, which only supports two: Nexus 5 and 7 (unsure if the first generation of Nexus 7 is supported).
So, you're reaffirming what I said (i.e. Google didn't do a good job) as their preview works only on two devices - their own Nexus 5 and 7 (not even on Nexus 10 or Nexus 7 LTE; it's safe to assume that the first generation of Nexus 7 is not supported either).
Really? Most of my software is prerelease. I'm writing this on Firefox Aurora, from time to time I'm using Google Chrome Canary, and I'm on Yosemite since day one together with Fedora Rawhide. So, please, don't tell me what to expect from prerelease software as I have a pretty good base for comparison. Let's stop setting the bar too low!
Edit: typos and grammar.
Alternatively, we could stop the total semantic dilution of terms like "beta" and "prerelease" that is prevalent among users who expect "beta" to mean "actually it's done completely now, there's nothing left anymore to be built."
Your approach sounds like a crappy manager who insists that because you sent something to QA, that means it's shippable RIGHT NOW LET'S GO ALREADY THE SHAREHOLDERS ARE DEMANDING IT
I've been using it as my daily driver on my Nexus 7. It's surprisingly stable for a dev preview. I only have one app that doesn't work with it, and the major freezing bugs only happen every couple weeks. It's probably not smart to use it as a daily driver on your primary phone though. If it causes problems on my Nexus 7 I'll only lose my play device for a little while.
I've been using it on my main device since July and haven't had any of the problems you've metioned :S The only problem I have is the Settings app ocasionally crashes when I try to setup a new wifi connection. But I don't do that nearly often enough to be upset about it. That said, I haven't noticed any improvements. It seems the same (speed / performance) wise as 4.4 on my N5.
Yes, even on 4.4.4, there was no noticeable difference between even ART and Dalvik. Again, that's why I wanted to use it daily as labs are one thing, but real world is often quite different.
Yes, even on 4.4.4, there was no noticeable difference between even ART and Dalvik.
On what hardware? I did not notice a difference on my Moto X. My Moto X is in repair now and in the meanwhile I have been using a Moto G. On that, I definitely notice a difference - app starting and multitasking is a whole lot faster with ART.
It's a developer preview, not a consumer preview. If you aren't running it on a second phone that contains nothing important, you are operating with a large amount of risk.
It's another oversold thing that will only create extra work for app developers who just finished catching up with KitKat design guidelines, I'm sure. The switch to bright is making a huge leap backwards!
