Slashdot Mirror
Android 3.0 Platform Preview and SDK Is Here
mikejuk writes "Google has released the Android 3.0 SDK, to allow developers time to create the apps that will run on the flood of tablet devices that should be availalble later in the year. The preview includes improved 2D and 3D graphics, new user interface controls, support for multicore processors, DRM and enterprise security features. It is complete with a 3.0 emulator that you can use to try applications on, but you can't add them to the app market just yet."
Not likely, and apart from various forms of trolls, there's no reason to.
You do not have a moral or legal right to do absolutely anything you want.
There is a reason to if it's likely that Oracle's lawsuits will be successful. If that came to pass, the handset manufacturers (or Google) would be required to pay Oracle. At that point it might be cheaper for them to use Windows Phone. Of course it may also drive the manufacturers to MeeGo as well.
Speculative future; oh hell yes, but there may be reasons for getting rid of Java.
http://developer.android.com/sdk/android-3.0-highlights.html
The enhancements including new/improved GUI controls and built-in animation support will make re-hosting features from iOS easier. There seems to be some confusion (possibly only in my mind) or overlap between Views, Widgets, Fragments, and Drawables as well as between Canvas and Paint. The whole framework seems disorganized or lacking consistent application of patterns, but I admit that I may just not see the forest for the trees.
Can you give some reasons why Java is bad for Android?
It might be even cheaper to Google to just buy Oracle.
Yes, Scala runs fine on Dalvik, as does anything that generates Java bytecodes (due to cross-compilation). Also check out the NDK.
Google might just end up making a new VM system, similar to what Microsoft did with .NET.
This might have some advantages. Perhaps language independence could be put in, so Java source code files can be used, but they would compile to the new VM format, similar to how Microsoft's J# compiled to .NET. This way, someone can use Java syntax, C++ syntax, heck, even a version of BASIC and still get the same bytecode coming out. Add JIT, and there would be little performance overhead.
Oracle doesn't seem to be doing much with Java anyway, so if Google made a VM system from scratch, perhaps it might be better overall in the long haul, especially if it was designed from the ground up for security, learning the mistakes Sun/Oracle made.
They're making a big deal about the new tablet features, but what does it add for phones? Will it even be released to phones? They don't even mention phones in their promo video. I hope they haven't forgotten about us...
In every application, users have access to contextual options, navigation, widgets, or other types of content in an Action Bar, displayed at the top of the screen.
Isn't this just a menu bar then? It seems like an odd idea for a tablet, basically it seems overly desktop like. Also unlike a desktop, the top of the screen may not be a fast place to house controls because on a touchscreen it's the furthest from where your hands naturally sit (at the bottom holding the device). In fact I'd say they got the Action Bar and the System Bar positions exactly reversed from how they should be...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Unless Google can whip out 166 billion from it's ass, there's a fat chance of that.
I used to be the biggest supporter of Nokia's Maemo/MeeGo OS. Except for the N770, I owned every single Maemo device they released (N800, N810, N900) and I loved them. They were true pocket computers running full, unlocked versions of Debian.
I still own the N900, which at the time it came out, was miles ahead of anything else available on the market in terms of features, customization, and hardware. It was amazing to have full desktop (not mobile) skype connectivity built into the phone. Just connect to wifi or 3G and make calls to any other Skype computer or N900. Full (not web) browsing enabled by default. Flash 9 preinstalled. But it is almost a year and a half later, and in the meantime Nokia has not released any new Maemo/MeeGo hardware, and only 1 major update to the N900 firmware. Even that update only fixed minor bugs and added the QT libraries.
In the meantime, Android went through at least 3 major revisions, and there are a multitude of devices to fit any need and budget. And now it matches pretty much all the features that made the N900 special. The worst part? Nokia hasn't even announced ANY MeeGo devices, let alone released them. They may still do it, but I think it's too little too late.
With a tablet android version, they might finally have gotten me into android app development. I'm not sure exactly how this works, would I have to learn and use java or could I just use any language?
"People don't want to learn linux" hasn't been a valid excuse since '03.
Android has it's own VM system, and it's called Dalvik. It has language independence built in so Java source files can be used... they compile to DEX, the Dalvik bytecode format. It does JIT.
Please tell me that the above was (well-disguised) sarcasm.
I agree with you, however I do suspect that, with most tablets, one hand is used to hold the device and the other is used to operate it. It seems to me that most every interaction should be one hand based for tablets. Its not clear to me where the easiest to hit area is on a tablet.
Phones on the other hand are often operated with the thumb of the hand that is holding the device, so in that case the bottom of the screen is pretty clearly a good place for frequently used operations.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
That's cool and everything, but can we get the *current* Android version for our Nexus Ones please?
Thanks. I have read much the same in the documentation. I suspect I just have to gain experience with the framework to get a feeling for which class to use when. For example, I don't see any reason why I can't draw in any old View rather than using a Widget, and Drawables don't seem to need Views at all; is that correct? I can have a Canvas and a Paint for a Drawable and see it on screen without a View?
I guess I'll just have to learn the intended roles of the classes. That is the nature of learning any framework and not necessarily better or worse with Android - just different.
This is the best bit from http://developer.android.com/sdk/android-3.0-highlights.html:
"Compatibility with existing apps
Android 3.0 brings a new UI designed for tablets and other larger screen devices, but it also is fully compatible with applications developed for earlier versions of the platform, or for smaller screen sizes. Existing applications can seamlessly participate in the new holographic UI theme without code changes, by adding a single attribute in their manifest files. The platform emulates the Menu key, which is replaced by the overflow menu in the Action Bar in the new UI. Developers wanting to take fuller advantage of larger screen sizes can also create dedicated layouts and assets for larger screens and add them to their existing applications."
Looks like this should run on existing platforms without too much tweaking by custom ROM builders/manufacturers.
In every application, users have access to contextual options, navigation, widgets, or other types of content in an Action Bar, displayed at the top of the screen.
Isn't this just a menu bar then? It seems like an odd idea for a tablet, basically it seems overly desktop like.
The 'Action Bar' isn't static, it's is customizable by the application so there is a standard place for all application controls.
I'll admit I am inclined towards C++ on these, but one has to admit given the variety of devices out there and potentially the variety of hardware that it could run on, having an abstraction layer like the VM does have it's benefits.
I'm sure that will happen around when Red Hat's acquisition of Microsoft gets past the regulators, and when Dell is in negotiations for the purchase of IBM.
The 'Action Bar' isn't static, it's is customizable by the application
In what way is that not a menu bar as on a desktop. It's the very definition of a menu bar...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I agree with you, however I do suspect that, with most tablets, one hand is used to hold the device and the other is used to operate it.
And I agree with that but even then, the top of the screen is still further from a resting hand than the bottom... when not in use the non-holding hand will not generally be resting in the middle of the screen or it would obscure content, it'll be sitting somewhere near the bottom or at the users's side. Even scrolling a list would end with your hand at the bottom of a screen.
Phones on the other hand are often operated with the thumb of the hand that is holding the device, so in that case the bottom of the screen is pretty clearly a good place for frequently used operations.
Even with tablets the holding thumb is still a very usable controller, and should not be ignored by tablet makers as a mere gripper.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Google, this is the enterprise feature your users really want.
Joy. I see it still has no owner.
the growth in cynicism and rebellion has not been without cause
Name an NIT feature Android doesn't offer at this point.
Android is far better for development than J2ME, I know as I used to do a little J2ME development - enough to know it was a lot of work to support most devices. Android makes most things much simpler and has a much broader set of frameworks.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The 'Action Bar' isn't static, it's is customizable by the application
In what way is that not a menu bar as on a desktop. It's the very definition of a menu bar...
It's meant to be context sensitive within the application, as opposed to a menu bar which is generally static per application. It is very menu-bar like but unlike iOS it gives the application a standard place to put controls when - and if - it needs to display them.
Since Google is the new Microsoft, it would be available only on Windows. Android may be based on Linux but this is a mere technicality.
From the video
at 0:19
Attila Bodis 12/21/2010
CONFIDENTIAL: Death ray hardware rev 2.0
- Hi Mike, Please don't share; this is just a [cut off]
Someday we'll hit the human carrying capacity. And the band will just play on.
The 'Action Bar' isn't static, it's is customizable by the application
In what way is that not a menu bar as on a desktop. It's the very definition of a menu bar...
It's meant to be context sensitive within the application, as opposed to a menu bar which is generally static per application. It is very menu-bar like but unlike iOS it gives the application a standard place to put controls when - and if - it needs to display them.
So more like some kind of "Ribbon" then?
There are plenty of reasons. Native code will always perform better and consume less battery life. Very important on a mobile device.
Google might just end up making a new VM system, similar to what Microsoft did with .NET.
How would that be different though? MS still pay royalties to Oracle (initially to Sun) for patents used in the .Net system. If Google loses the case with Oracle over Java they will end up paying royalties just like MS does now.
Perhaps language independence could be put in,
I remember reading about Java years ago when it was new. One of the things they seemed proudest of was the VM, since it would allow many languages to be combined. Perhaps it was mis-designed and ended up begin Java specific, but I thought there were other languages now available.
SJW n. One who posts facts.
I guess, but without retaining whatever else is there. So where ribbon changes tabs based on the application context the Action Bar would replace the items not relevant in the current context.
Google did a bang up job kneecapping open source efforts in the mobile space, convincing the community to chase after an environment that discarded pretty much every existing open source tool in the name of NIH and withholds new versions from the community until their partners are done getting their releases out with it.
Then they sit back and have the nerve to tell us that Android is "open" while users are forced to jailbreak and deal with vendors that try to cripple devices so they can leverage later versions as a selling point for the next carrier contract.
I hope that MeeGo takes off with non-asshole hardware vendors, if not the we might as well right off the mobile computing space as being property of Microsoft, Apple, and Google.
That's interesting, so Ribbon meets MacOs (not iOS) menu bar?
Scala, Python, Ruby, Closure, Groovy and a few more.
Dilbert RSS feed
Sure if you want code that still runs just as crappy as the regular stuff since it all still runs in the VM.
I'm not sure you understand what it means: it doesn't actually compile C/C++ to bytecode, it runs native code, which interfaces with a virtualized machine. So no, it doesn't run "just as crappy".
The drawback of having to be a competent programmer rather than a mouth-breathing Java code slinger?
Considering the Android platform, which runs on everything from ARM smartphones, TVs and tablets to x86 laptops, a JIT that can optimize to any specific architecture at runtime will probably outperform the native code objects, since no developer has thousands of dollars and enough time to optimize, test and debug for each CPU model.
But I'll get off your lawn now.
Dilbert RSS feed
Yeah that seems a pretty good way to describe it. Personally i like the idea, im not sure what the OP found to be 'dangerous' about it.
I think android is moving to fast. In the last year we saw 2.1, 2.2, 2.3 and now 3.0. I think they need to scale back to annual releases because phone makers don't or can't keep up and then people end up upset because they are not on the latest version of the OS. Also not everyone wants to root their phone and install some cyanogenmod version or other hacked version. I'm not saying that there is anything wrong with people doing that, but the average phone user wants to buy a phone that will not be out of date in 6 months. I also realize that not all android phones suffer this, but there are many that came out with 1.x last year and still have not been upgraded to 2.x and many wont see 2.3. When apps stop coding to the 1.5 version and 1.6 version as many are doing that makes a phone that is less than a year old outdated and then upsets customers. If you are on a 2 year contract then you screwed after 6 months, you will probably not be doing an android phone again and now that iphones will run on verizon this could be trouble for android.
Only 'flamers' flame!
a JIT that can optimize to any specific architecture at runtime will probably outperform the native code objects, since no developer has thousands of dollars and enough time to optimize, test and debug for each CPU model.
What the FUCK is this shit?
Code compiled to actual machine code will always be faster than something that has to be compiled on the fly.
Most developers worth a damn DO have "thousands of dollars" and plenty of time to test, debug, and optimize for many platforms - they choose not to test in general because no one hold developers responsible for their fuck ups anymore.
And they'd get no additional benefit to testing the same code across multiple platforms. Either it works or it's the platform's, or rarely, the compiler's, fault. This is why you design for the lowest common denominator of the hardware you plan to support.
Developers don't have to spend vast amounts of extra money or time to compile or test for different platforms. You just set a fucking flag for your target architecture when you call your compiler. If it builds runs, and in general doesn't explode, it's as good to go as it was on the other platforms. Any cross-platform fuckups at this point would occur with a VM setup as well.
They call it Java, but technically it's not Java... it doesn't run on a JVM, and uses a custom development kit (not the JDK).
From: http://en.wikipedia.org/wiki/Dalvik_(software)
"Dalvik does not align to Java SE nor Java ME Class Library profiles[8][9] (e.g., Java ME classes, AWT or Swing are not supported). Instead it uses its own library[10] built on a subset of the Apache Harmony Java implementation."
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
I'll admit I am inclined towards C++ on these, but one has to admit given the variety of devices out there and potentially the variety of hardware that it could run on, having an abstraction layer like the VM does have it's benefits.
It has its benefits within the platform scope, but not when it comes to porting across platforms.
They call it Java, but technically it's not Java...
It's Java in the sense that the language used is Java, any Java programmer can code for Android because the language used is Java.
it doesn't run on a JVM
Using the android development kit the generated bytecode doesn't run on a JVM, but the code can by compiled to JVM bytecode because it's Java.
and uses a custom development kit (not the JDK).
It doesn't support the full JDK because it discards parts of the Java class library - that aren't really relevant or suitable for Android - and uses it's own.
Down to the VM it's all Java, it's just that for Android you generate Dalvik bytecode instead of Java bytecode, which doesn't make any difference for the developer.
Oracle's lawsuit is because Google created their own VM system rather than copying the JVM. Oracle believes that any VM system that infringes on their patents (basically any VM system more modern and efficient than the UCSD p-System) should either be compatible with the J2SE specification, or should be licensed with Oracle getting paid out of the deal.
You are not alone. This is not normal. None of this is normal.
This is why you design for the lowest common denominator of the hardware you plan to support.
My whole point. The JIT can actually use each hardware's capabilities, by compiling to machine code specifically for it. And considering that with the multitude of platforms for Android, the lowest common denominator may be very basic.
Dilbert RSS feed
DANGER DANGER! ...actually that sounds a little sensationalist...what's 'dangerous' about a menu bar?
Ask Windows how they have fared on tablets for the last decade that stuck to the desktop metaphor,
The danger is to Android.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
it's not required, but it helps a lot. It's one the major advantage of opensource over proprietary.
being compatible means a lot of code re-use.
code re-use means faster development and better security, because whatever (patch,new feature) done for one platform automatically benefits all the other using the same code. (Linus' law requires as much eyeballs as possible).
and having to *root* your very own phone you bought yourself and which is running opensource software ? That I find not exactly acceptable.
i ended up buying a palm pre. Okay, the webos' UI (luna) is partially closed source and proprietary. But there's no rooting/jailbreaking madness required to run custom code on it. Including a customised kernel.
I really hope webos and meego gather some momentum,and grow in quality. It would be sad if the only presence of linux in the smartphone world is the current " it's open but you have to hack it anyway" situation.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Stability, architecture are also very important in phones. Apps written in a VM decrease the likelihood that they will destabilize the system such as by crashing unexpectedly, passing duff data around to other apps, accessing devices or files they have no permissions to access, consuming resources, hogging CPU or otherwise causing the phone to bug out. Using a VM also means it is largely irrelevant what chipset is sitting underneath because the app in the VM doesn't care.
Of course Google offers a native dev kit too, but frankly unless an app (e.g. a app) absolutely needs the performance it would be better off sticking in a VM. I'm surprised they don't also offer llvm support so devs can write bitcode portable executables.
The preview includes improved 2D and 3D graphics [...] complete with a 3.0 emulator
Any word on the speed of this emulator? Running the 2.2 emulator 1.6GHz box, it takes several minutes to start, and then crawls so slowly that the screen is filled with "I can't tell whether the app is running slowly or is just dead" warnings -- If there haven't been improvements, I dread to think what the performance would be like for 3D graphics on a tablet-size screen...
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Meanwhile, don't worry -- your Android device won't become less useful over time.
Unless software designed for connecting to a specific server gets updates, the updated version is incompatible with your device, and the non-updated version is incompatible with changes to the server's protocol.
It has happened before in PC MMO gaming, when the server required all players to upgrade to the new version of the client, and this version didn't run on Windows 98. I don't remember precisely which; was it EverQuest?
I don't have a smartphone. The Android device that I do own did not come with the Android Market application. Just as you extrapolated that an "Android device won't become less useful over time", I too am extrapolating, in this case from experiences on Windows to the potential for experiences on Android.