64-bit Android L developer preview | Hacker News Reader

64-bit Android L developer preview

plus.google.com

75 pointsnantunes65 comments

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.

Tell me about it. And if you dare to mention it, then "Well nobody else has reported this problem". So next time you don't bother.

What? I have the same problem. It starts as blank. Nothing happens.

title should say 'emulator' or it is mostly pointless.

Sidenode - Chromium 37.0/Ubuntu bug - crashes if I attempt "right click-save link as" on any of the download links here https://developer.android.com/tools/sdk/ndk/index.html#Insta...

Anyone else seeing this?

Edit: Found it - https://code.google.com/p/chromium/issues/detail?id=357473 - carry on.

Intel had been pushing hard for supporting x86 based devices running Android. Glad to see it coming thru for Android developers with L release.

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.

It has supported for a long time but that's for C++ native development not for Java developers. This is a big change in x86 support in L.

Which other comment, I never said it doesn't matter.

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.

Uh, no it isn't? Dalvik has had x86 codegen since ICS: https://android.googlesource.com/platform/dalvik/+/ics-mr0/v...

And that's for JIT codegen, the interpreter will obviously run just fine on every architecture.

MIPS becamse first-class supported in KitKat, by the way.

Android's been running on x86 in my living room for 4 years. The original Google TV box (Logitech Revue) has an Intel Atom inside.

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.

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?

https://github.com/android/platform_external_qemu

Unfortunately it doesn't come with support for what really matters: 64-bit ARM. Support for Intel's 64-bit chips is irrelevant.

It's not irrelevant, think TV's, Gaming consoles etc are much better off with Intel processor than Arm.

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.

Consoles make no sense with Intel chips, just for cost reasons.

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.

I was talking specifically about chips made by Intel, not x86.

Uhm... Android L will certanly support 64-bit ARM and the support is in the new SDK and NDK.

This is just an emulator image so you can test compatibility with 64-bit targets.

So why are they making a big deal about Intel's chips then. Where is the ARMv8 ISA support?

Most likely coming with the new hardware at L release.

Who's got 64 bit ARM in a handset other than Apple? x86 is the way to get to 64 bit hardware fastest.

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.

64-bit address space significantly improves ASLR protection.

It's fair to say ASLR is about 4 billion times better with a 64 bit processor.

ARMv8 has more registers in addition to 64-bit address space support, so almost all applications should benefit from the minimization of register spilling.

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?

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.

It's a developer preview, which by definition is not something you should run on your primary phone.

Yes, I'm a developer, and I need to test in the real-world, not in a lab to get a real feel of it.

That's why I have more than one phone. Besides, I want to know how what I build works on more than one device.

So, I need 2? One iPhone, which doesn't have issues with prerelease versions, and two Android ones?

Android is a very diverse ecosystem

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).

It's fairly common to test your Android apps against a multitude of devices. There were times I had more than 5 different smartphones on my desk.

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).

Not sure what you're expecting from a preview released several months before release.

I haven't been using Android L. I've only been using the Dev Preview of Android L which I assume you are too.

I haven't had a single problem with it, I've been using it for months and love it.

Atleast you got it..non Nexus devices can't even play with L yet :(

This line:

> 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.

I got a gazillion updates from Yosemite and Xcode.

Yes, but Google's goals was never to run a semi-public beta. The L developer images were provided so that developers can develop/test their apps on L.

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.

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.

On Nexus 5 (Android L preview is only for Nexus 5 and 7).

Stability complaints while using a beta product that that is introducing big underlying changes to the platform. Classy.

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'm sure you've used Gmail for years when it was beta like many other software. Dual standards!

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.

Did you at least like the design language they borrowed from Microsoft?

Microsoft has pseudo-3D with multiple planes and realtime-computed shadows now?

No, I think they dropped this since Vista. There is a pinch of old-school, you are right.

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!

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.

Reply on news.ycombinator.com