Android 4.0 SDK Now Available | Hacker News Reader

Android 4.0 SDK Now Available

developer.android.com

182 pointsToddward78 comments

  Beginning with Android 4.0, hardware acceleration for all
  windows is enabled by default if your application has set
  either targetSdkVersion or minSdkVersion to “14" or higher.
  Hardware acceleration generally results in smoother
  animations, smoother scrolling, and overall better
  performance and response to user interaction.

This is great news for users like me who couldn't stand Android's low-framerate animations. But what's sad is that it took them so long.

A number of my friends point to Android's laggy scrolling as the reason they wouldn't consider it over an iPhone. It'll be interesting to see if the hardware acceleration fixes this defect.

I've never noticed laggy scrolling and I don't even have a current gen phone (Droid X). Perhaps your friends have other reasons for not considering it...

Edit: Maybe because I've always used launcher pro?

Even with Launcher Pro, other parts of the OS can be laggy. (Though Launcher Pro is amazing.) But I thing the more accurate term would be choppy. You don't notice it that much until you use another platform for a small amount of time. Then going back it is very noticable.

Gingerbread fixes some of the "lag" issues with the partly GPU accelerated UI, mostly noticeable in the notifications pull-down menu.

Opera Mobile (GPU accelerated), with a decent launcher, memory optimizations (V6 Supercharger, or a good Autokiller config), and Android will perform just as good as any other mobile OS. Unfortunately to get great performance Android needs to be rooted.

That is it. I find my android phone animation perfectly acceptable until I tried an iPhone. Even a Windows Phone 7 feels better. I really hope android 4 address this problem.

The choppiness in the UI is awful, but it's not solely the result of a lack of hardware acceleration (though it's no doubt a contributing factor).

Google have said [1] that it's primarily the result of lots of GC rather than drawing performance.

[1] http://code.google.com/p/android/issues/detail?id=6914

And they have somewhat mitigated that as of Gingerbread with the new concurrent GC.

VPN client API

Developers can now build or extend their own VPN solutions on the platform using a new VPN API and underlying secure credential storage. With user permission, applications can configure addresses and routing rules, process outgoing and incoming packets, and establish secure tunnels to a remote server. Enterprises can also take advantage of a standard VPN client built into the platform that provides access to L2TP and IPSec protocols. http://developer.android.com/sdk/android-4.0-highlights.html

Does that mean we'll get a Cisco VPN client? That will be a killer app.

Probably, but will enterprises ever allow devices that don't have remote-wipe? (You can pretend to have remote wipe with Android, but backup software is very easy to write and have run every night, and good luck remotely wiping my S3 space. There is even software that will copy your entire flash image to S3 or Dropbox at timed intervals. Not compatible with "we don't trust our employees".)

Remote wipe is starting to appear on Android devices. Check the Samsung Stratosphere that was released this week. It also has Cisco's SSL VPN client on it.

http://www.talkandroid.com/65998-verizon-wireless-officially...

That funny word "enterprise" to me means that in fact the employee is not trusted so here's the device that's been chosen for you and your app market has been provided by the IT staff. If you need assistance, contact the help desk but be forewarned they they are fully engaged supporting Windows 95 and NT because the budgeteers have decided IS is a scary cost center.

Remote wipe has been available for ages - there are at least five apps from well-established companies that offer it. The latest was Norton iirc. Samsung phones come with it by default, you just have to enable it (samsungdive.com)

Google already provides remote wipe and other domain management with the Google Apps Device Policy app. Domain owners can require users that want to link an account to their phone to accept the device policy, which can include remote wipe permission, remote lock, etc.

Source: https://market.android.com/details?id=com.google.android.app...

Yeah, but Android is not locked down enough to implement real remote wipe.

I really do not care about enterprises. I want to reach my servers securely via OpenVPN.

Killer app?

iOS has had Cisco VPN support since 2.0.

It looks like Cisco already has a few VPN clients for Android, although it looks like they are either device specific or require root.

https://market.android.com/developer?pub=Cisco+Systems,+Inc.

This actually sounds like something Cisco would integrate into the Cius and any other Android devices they make. Though the Cius is built on 2.3 and a lot of effort would probably need to go into migrating to 4.0 (even to get to 3).

Check out http://developer.android.com/sdk/android-4.0-highlights.html -- a lot of dubious stuff, but these seem legit:

* cool "continuous dictation" * faster browser (thanks to V8) * wifi direct (!!? http://www.youtube.com/watch?v=je2lWjfpywQ )

The "unlock via face recognition" feature looks cool. But I guess someone can just take a picture of your face and show the picture to the phone to unlock it. Oh well, it seemed cool for a few minutes :)

It's a limitation/drawback of face recognition technology as a whole. I would not consider it as Google's.

One can still blame Google for choosing to use a flawed technology.

If they chose ROT13 for encrypting user data, would you say "It's a limitation/drawback of ROT13. I would not consider it as Google's fault to use it"?

When I saw them unveil Face Unlock, and then have the demo fail on stage, I immediately wondered why they were even bothering with such a gimmicky feature... and your 'photo imposter' scenario is realer than most people believe [1].

[1] PDF: Paper by Nguyen Minh Duc and Bui Quang Minh from Bach Khoa Internetwork Security Center/Hanoi University of Technology

http://www.blackhat.com/presentations/bh-dc-09/Nguyen/BlackH...

No feature is perfect. This still protects against data theft or prying eyes if you lose your phone, my primary concern.

Those finger-swipe locks that people seem to be so fond of on my University campus are less secure than decent facial recognition software IMO. Hypothetically I could find a phone left behind in the library and see their passcode pretty clearly in their finger smudges on the screen. Do you remember to wipe your screen clean every time?

Facial recognition will not deter someone who is deliberately targeting you, no. Maybe some combination of facial recognition AND numeric-passcode would be more suitable.

I am wondering how this works in low light situations.. Also i guess the "pattern to unlock" works faster, more reliable and is just as unsafe... Although it's easier to guess the finger "smears" on the display then getting hold of a picture of a phones owner..

I am wondering how this works in low light situations..

It detects the light conditions via the sensor and auto-flashs you when necessary. Nice while driving at night.

I can't tell if you're being sarcastic or not - does it really flash if it needs the light? That seems…awful.

The demo video showed the screen saying there wasn't enough light and then reverting to the gesture lock.

Security vulnerabilities aside, I just don't see people gravitating towards this.

Pick up phone, hold it out at arm's length in front of you. Hold it real still. Now wait. Bloop bleep boop now it's unlocked!

Compare with:

Pick up phone, swipe your unlock gesture. Hurray!

For something the user is doing constantly, many times, every single... I just don't see why anyone would pick the more uselessly time-consuming (and more effort required) option.

Lock the phone and carefully look at the screen from a few different angles. Chances are that you can clearly make out the greasy trail of the unlock pattern. I switched back to a PIN code when I noticed this.

Check out this video: http://www.engadget.com/2011/10/19/ice-cream-sandwich-face-u...

It seems quicker than swiping an unlock code.

I think it could be useful if the camera has a zero shutter lag as it is in the nexus. A scenario coming to my mind is maybe hands-free interaction with voice commands while driving. Anyway, it don't think locking a phone has a security connotation here, but it is a way to avoid any accidental launch of application/typing.

Fair enough, but can you imagine the press hoopla had Apple introduced this feature?

One way they might improve on this could be that it takes 3 pictures and makes sure that there was some slight movement in the person being ID'ed.

It's still wouldn't be secure, but it'd mean attackers would need a video of you instead of a simple facebook photo.

Main concern would be slowing down the user.

Or make it so that the user has to wink at the camera to unlock it ;)

It's a step above a pattern/PIN lock; with a minimum drop in convenience. No smudge trails left on the screen, can't be easily guessed, and you have to know who the owner is before you can unlock it. Not as secure as, say, a fingerprint scanner, but it's also easy to implement on existing devices.

> No smudge trails left on the screen

Surely you're still going to touch it after you've unlocked it? :-)

i think the parent was talking about the security implications of having your unlock pattern show up on the screen. it's entirely possible to not touch the screen enough after unlocking to wipe out your pattern.

http://whispersys.com/screenlock.html

How about the source code? Anyone know what the status of that is?

I'd like to know that too. Google's recent lack of openness with Android source code has been disappointing.

I am not sure on a release date, but it has been said that they will be releasing the source code for ICS, unlike what they did for Honeycomb.

If Android Keeps going this way I might do more Android Development in the future, IMO by version 5, android will have an mature API - not that now it doesn't this is jut my opinion. As an Apple fan boy is nice to see that iOS is getting some healthy competition - in the end both platforms will win if the competition is High.

My Context: I only did iOS development and a little Android. I love apple technology because works so well and is so well integrated mainly with their products.

Google really needs to provide an action bar implementation in the compatibility package (for 2.3 and lower) if they want developers to port apps over to ICS.

I'm really hoping they do, and soon, because I'm just about to hack together an action bar for my 2.1-2.3 app.

There you go: http://developer.android.com/resources/samples/ActionBarComp...

Probably not exactly what you expected, but should do the job

Excellent! I was waiting for them to do a developer's blog post on backwards compatibility, but this is a huge help on getting started.

This is exactly what ActionBarSherlock[0] does.

[0]: http://actionbarsherlock.com/

I'm using sherlock in a few projects but ActionBarCompat mentioned below might be the way to go in the future.

Finally, SVG support for Android handsets!

See this long-standing issue: http://code.google.com/p/android/issues/detail?id=1376 where their stated reason for leaving out SVG was to save 1MB of space in the WebKit image size.

Audio performance is still dismal. I had really hoped that Android would catch up with iOS in the audio latency department with this release, but my tests so far don't indicate much attention on this deficit yet. A pity, Android tablets would make good synthesizers too ..

Have you tried Caustic? That seems to be hitting a sweet spot.

Haven't tried it yet but I will as soon as I can ..

Okay, tried it. Very nice app, wonderful features - but the latency is terrible. I hope we see some improvements in this regard, otherwise iOS will always rule this realm.

Really? That's a shame: I was hoping vaguely that the OpenMax AL stuff might get that bit closer.

"Android 4.0 provides a direct, efficient path for low-level streaming multimedia" http://developer.android.com/sdk/android-4.0-highlights.html

I've been on the Android audio latency trail since 2009, and recently spoke to some platform developers who've hinted that something is finally on the horizon. I'm too tired of the situation to be blindly optimistic about it, but maybe just maybe...

Fine for streaming .. but audio generation/synthesis? I think not.

It really depends what it gives us. For synthesis what you want is to be able to stream bytes to audio out. You can currently do this with AudioTrack but it goes through IPC and is generally slow. Personally I'd call that a use case for "streaming multimedia" but who knows what it will actually cover.

Doesn't look like there's a way to simulate two NFC devices with android beam, which is a bit of a bummer, Android Beam support fits the intended use case of my iPhone app I'm about to port to Android (http://convoyapp.net) but as an independent developer I've already spent enough money on gadgets, can't afford to buy TWO NFC enabled ICS devices for testing purposes.

On that note, is there any service that lets you hire devices for dev/testing purposes? Would be great to get access to a lab with 20 different Android devices (for debugging obscure device specific bugs/screen size differences) along with all ipads, iphones, iPod touches and some WP7 devices.

Yes, this. Company gives full access to devices over the Internet on an hourly basis:

http://www.deviceanywhere.com/mobile-application-testing.htm...

Pretty cool service

Genuine question: did they announce when the source code for ICS will be released? AFAIK, http://android.git.kernel.org is still down, I can't seem to reach http://android4.git.kernel.org and http://source.android.com/ still lists Gingerbread as the latest source code drop available.

I can't envisage it being released before the first ICS phones hit the market (for relatively obvious reasons), and can easily imagine it taking at least a month from then.

Has anyone been able to successfully launch a 4.0 AVD image in the emu? I keep trying, but all I get is the boot anim. I also noticed that the arm image is updated to v7a.. :/

Try closing it and starting again. Give it at least 5 minutes. Took me a few tries.

Oh, and (as expected), they've somehow managed to make the emulator even slower now.

yeah it took awhile to start up..

increase device ram in your AVD settings to 512

Increase it to 1024

How the hell do you make the emulator slower than it already is?

Feature creep.

Its an emulator. Its not going to get faster if you throw more software at it. This release includes a lot more extra software.

That's weird, I thought I had read somewhere that the next release was going to speed up the emulator.

the thing wouldn't even load on my dell netbook (AMD fusion) but was totally fine on my iMac

I wish they would supply a C/C++ debugger option. As it stands now we are stuck using printf like we did on other platforms in the 80s.

Have a look at ndk-gdb in the root of the NDK directory.

Check out the sequoyah eclipse plug-in. Makes it much easier to manage/debug ndk code from within eclipse.

Good news for web support improvement. probably still a long way to go to reach iOS advancement. I hope we reach it ;)

I wonder when discovering peers with wifi direct, can I be connected to another wifi network in the meantime?

It took them until version 4 to release an (official) calendar API?

When are the old nexus devices gonna see their version?

Reply on news.ycombinator.com