Slashdot Mirror
Android Ice Cream Sandwich SDK Released
Hitting the front page for the first time, ttong writes "The highly anticipated Android 4.0 (codenamed Ice Cream Sandwich) has been released and finally brings the features of 3.x Honeycomb to smaller devices. Some of the highlights include: a revamped UI, a much faster browser, face unlock, a vastly improved camera app, improved task switching, streaming voice recognition, Wi-Fi Direct, and Bluetooth Health Device Profile. ... The API level is 14, download the new SDK here."
calc noted that the source code has yet to be released (Google account required) except to legally required GPL components. Supposedly progress is being made toward getting AOSP back online: "We're working on it and we're making good progress, but we're not ready to announce any additional details yet." How many of the new features will remain proprietary and tied to Google services remains to be seen.
is the miserable battery life. My droid Incredible goes barely a day and a half with little to no good smartphone usage. If I use the internet or video at all the battery is gone in less than a day. I even have all the default auto-running programs deleted. I will probably go back to iphone after this just because of its incredible battery life. I had the 3g and it was amazing.
I hear that complaint a lot, and even made it myself when I had an Evo4G. However, I found that if you disable all the features that are not present in the iPhone, like 4G, live wallpaper, widgets, flash, live weather, etc, I think you'll find the battery life to be comparable to what you had on your iPhone. My Evo3D is as good or better than my buddy's iPhone4 by simply turning off live wallpaper and 4G.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
They do use version numbers; Gingerbread = Android 2.x, Honeycomb = Android 3.x and Ice Cream Sandwich = 4.x This way satisfy the enthusiasts craving for a sweet desert and the professional's need to not sound like an enthusiast.
wow you're boring.
I just finished the cassowary version and now I'm working on the dingo version. Yes we use those terms in meetings, with bosses, and it gets a good chuckle. It's far more entertaining than version numbers.
I'm god, but it's a bit of a drag really...
face unlock
Does that mean if someone steals my phone and my wallet, all they have to do is hold the drivers license up to the cam to unlock? Sounds like a very bad idea.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Gingerbread = 2.3 more precisely. 2.1 is Eclair and 2.2 is Froyo.
That's been a huge issue for me too. I went and got the extended battery for the Evo 4G which worked wonderfully, although it made the phone heavy as a brick. I've found a surprising solution though. Recently upgraded to the Galaxy S2 (Or whatever the hell you call the thing) and there wasn't an extended battery available yet that I could find. So, against my better judgement I tried JuiceDefender. It works. It works *well*. Basically it shuts down the sensors when they aren't in use, and turns them on when you unlock your phone to use it. Worried about email? No problem, it turns on the data every so often to allow apps to synch that need to synch. I'm actually not sure why a similar strategy isn't just a default part of the operating system.
I worked on a project with another Doctor Who fan and we were perfectly fine with upgrading Jon Pertwee to Tom Baker.
I'm glad I got laid off before I had to go from Sylvester McCoy to Paul McGann. Although if we made it to version 10, we had the idea of naming 10.5 "Handy."
Non impediti ratione cogitationus.
If Google had invented the universal translator, they might have made a slightly bigger deal out of it.
So my guess is that it's limited to the languages you specify, just like the keyboard.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I just hope that my phone gets updated to this. I'm still stuck with Froyo and my phone just came out in July. That's one of the most frustrating aspects of Android phones - the manufacturers do not upgrade the phones. With the quick turnover in phone OSes, it's inexcusable for manufacturers to stick with old OSes. I can understand if the phone hardware cannot handle the upgrade but I know that many phone manufacturers simply do not want to support their devices. Instead, to get updates we have to turn to CyanogenMod. This is one reason iPhones are so popular (yes, I know Android is overtaking iOS but the iPhone is the most popular smartphone model), at least Apple does a good job of updating iOS and getting it to as many iPhones as possible.
All this being said, Android 4.0 looks great.
The API is horrible - standard Java classes replaced by poorly designed alternatives for no apparent reason
So your rationale is that the API is horrible because they added in some bespoke classes? In the platform developer's opinion, those classes are better suited to mobile devices. But, guess what, you don't even have to use them. What Java classes did they "replace" that aren't still there? I haven't found anything in particular that has been replaced, they just gave you the option of using the newer stuff. The analagous Java class is still there. And how are the new classes poorly designed?
those horrible XML files as the preferred way of designing a UI
Er, if you don't want to use XML files to do your UI, you don't have to. You can use pure Java all day long. Besides, the XML files are exploded into Java on the device anyway. You use the XML to quickly design the static elements of your UI and use Java code to do the interactive stuff. What is there to bitch about?
When I got to the bit in the tutorials about apps being forcibly restarted when the orientation changes I cried with laughter.
This is not even true. The activity does not "restart", the ui reinitializes to use the layout prescribed for that particular orientation. You don't want a long list of single column buttons in landscape, you want them more logically laid out so the UI for the activity restarts. It is trivially easy to keep all of the ui data like form contents, etc. and reinsert it into the layout when the screen rotates and it happens instantly so the user isn't even remotely aware. Poor app developers that don't take the very small amount of time to make this happen is what gives it a bad rep.
It feels a proof of concept rather than a polished development platform
Nothing you've said supports this conclusion. The points you make are what I would expect from someone that is looking for a reason to hate before he's even given the platform a chance.
The soylentnews experiment has been a dismal failure.
those horrible XML files as the preferred way of designing a UI
Hmm...separating the UI description out in xml files is a good thing. In fact, it's a standard thing across all platforms. Android has those xml files, Windows has xaml, and iOS has .xib files.
Sure, interface builder abstracts you from the .xib files, and you never have to look inside it, but you can do xaml and android xml via their respective design interfaces too. The fact that you can also edit the xml manually is a feature, not a bug.
Actually its not random. The Android releases are being done in alphabetical order.
2.2 Froyo
2.3 Gingerbread
3.0 Honeycomb
4.0 Ice cream sandwich
get it?
When I got to the bit in the tutorials about apps being forcibly restarted when the orientation changes I cried with laughter
Err.....lolwut? Was it perhaps a how-to-spread-FUD - tutorial?
I looked at the implementations of the alternative to many of the Collections classes in particular, and they had nothing in them that suggested they were "better suited to mobile devices". And I'm not going to dig through the API docs, but they were certainly no improvement on the equivalent Java classes, and I recall them often being less intuitive.
The use the Java classes. Why complain about choice?
I know you can construct your UI directly in code, but virtually all the documentation I have seen assumes you'd never want to do that and omits coverage of it. Hence why I said the XML format was presented as "the preferred way".
Yes, because the XML way is going to be easier and more intuitive for many people. For the hardcore olde thymers such as yourself, you can use Java. Again, the choice is yours.
The process is exactly the same as when the app is explicitly shutdown by the user or the app developers code, so it is true. That's why you have to store the current state of the application, as you allude to in your comment.
No, it most assuredly is not. Android apps are not like desktop apps. The lifecycle is totally different and more suited to an "on-the-go"/everything runs fullscreen device. onCreate initializes the logic of your activity and it is called once when that activity is first run. When you shut down an app explicitely, it calls onCreate when you go back to it. When you rotate the screen, it calls onPause and onResume so that your portrait layout (for example) isn't just jumbled together and resized for landscape. You can have a completely different layout for the two modes. Or you can just use onPause and onResume to fill form data back in and to hell with having multiple layouts. When the screen is rotated, everything done in onCreate is maintained that includes all variables, etc. You save form data with onPause and refill it with onResume. It's trivially easy and in the context of the system makes sense. I'm not a teacher, I'm a programmer so my explanation likely sucks. My suggestion is you read this.
Well, if you feel it's more than just adequate then I dread to think what your own code looks like.
Because I disagree with you and think Android is an elegant system to develop for, that means my code sucks? I'm sorry, who are you and what are your credentials again that I should just slavishly follow what you say? When you can give me compelling reasons for why Android supposedly sucks (and you haven't), I'll believe it. So far, you've just given biased opinions based on your impressions of a platform that you don't code for and obviously don't have any real intentions of even giving a fair chance. With that attitude of inflexibility, I'd really hate to see your code.
The soylentnews experiment has been a dismal failure.
A marketing company lying? Say it isn't so!
Honeycomb does provide that, so I would also imagine ICS providing that. Perhaps someone just forgot to mention it?
Pretty big thing to fail to mention! It's fundamental to Android being a contender to Blackberry in the corporate world.
Finally had enough. Come see us over at https://soylentnews.org/
Use a body part that isn't visible in your ID photo.
I'm the real Vorokrytin P. Winterbuttocks.
Google made it clear from the beginning that Honeycomb wasn't going to be opened. There's been no problem getting the source for Honeycomb's mobile peer, Gingerbread - I'm running it right now courtesy of Cyanogen.
I don't like the fact that Google didn't open Honeycomb, but they had their reasons, and I respect them. Unlike ICS, Honeycomb was always a rushed "production" beta, and Google didn't want developers working from it. ICS, on the other hand, is the future direction of Android. There's no reason to suppose that Google isn't going to release the source for it, as failing to do so would pretty much kill the platform.
You are not alone. This is not normal. None of this is normal.
Not quite. Orientation changes do, in fact, terminate and restart activities. It works fine if you do literally all network activity with background services and strictly observe canonical model-view-controller design, but kills newbie Android developers left, right, and diagonally, and is the single biggest reason why so many non-MVC Android apps forcibly lock views to a single orientation (the only way to prevent it from happening).
You can tell the scheme was originally concocted based on the G1's hardware -- flip out the keyboard, the screen rotates. A specific, unambiguously deliberate act. The problem is, they extended rotation to the accelerometers, and all hell broke loose because you started to get spurious, accidental rotations caused by users holding the phone in their hand and changing its orientation when something else captured their attention for a moment (like the cashier at a store or fast food restaurant, or putting the phone down while driving because the light turned green). The teardown behavior is sensible in a pure MVC design, and is tolerable when orientation changes are deliberate and rare, but breaks down and becomes totally dysfunctional when you add the current accelerometer-driven orientation dynamics.
Don't get me wrong -- I think accelerometers are a great way to determine orientation. I just wish there were a big, easy to deliberately press (and hard to accidentally press) hardkey that meant, "take an accelerometer reading now, and adjust the orientation if appropriate. Then stay that way until I press the button again". Right now, with tablets like the Xoom, you're forced to either lock the orientation (and go through 20 seconds of annoyance to switch between portrait and landscape), or deal with endless spurious orientation changes that seem to be far easier to trigger than to undo (ie, a slight tilt in the wrong direction changes the screen, but when you try to get it to go BACK, the new orientation is "sticky" for a few seconds. Pure frustration.) In the Xoom's case, I'd overload the power button so that a rapid double-press (that would normally turn off the screen, then turn it back on with the screen lock annoyingly activated even though the screen was only off for ~300 milliseconds) would trigger an accelerometer reading and orientation change.
The other hugely stupid thing Android did that causes endless misery, and will probably cause misery forever, was to implement a SUBSET of BouncyCastle without changing the namespace, which totally fucks up any program that needs to use a part of BouncyCastle that's not part of the core API. You can't just drop the BouncyCastle jarfile into your project, because then you get namespace collisions and Bad Things Happen(tm). So, you have to basically take BouncyCastle, then rebuild it with a different package name, then change every reference to use your new namespace instead of the original.
Loads of people here care about the Android sources being available. Personally I work with the Android source, and need it available to me where possible. But for people who don't, many of them still want to be able to use Cyanogenmod or other ROMs developed from the source. Even if they don't see it personally, they can get benefit from it.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
That's pretty much a gross exaggeration of battery consumption. Not only that, but you seem to keep comparing battery life for Android phones under heavy load to the expected battery life of an iPhone under ideal conditions with no use. Apple doesn't own some magic technology that lets its phones do lots of work with no negative impact on battery life; they drain just as fast under heavy load.
I have my Evo 4G with me all the time with bluetooth enabled and I easily get 2 days out of the battery unless I'm doing a lot of web surfing or playing a lot of games.
--Jeremy
Jesus was a liberal
In addition to what the other responder said about android:configChanges="keyboardHidden|orientation", it's possible with most mobile platforms for the application developer to include a soft-button in their interface that does what you describe.
Personally, I do actually like the feature on the Xoom, included with Honeycomb 3.0, that allows one to globally lock screen orientation. Short of the 'orientation-flip' button you describe I find it a fairly reasonable alternative.
I'm not arguing that the 'orientation lock' feature shouldn't exist, just arguing that it would be nicer to use if a power button double-click were interpreted as "reorient the screen based on the accelerometer now, then lock it until the next time I double-click the button". A separate button would be even nicer, but making do with the hardware buttons the Xoom already has, a powerbutton doubleclick is just about the best unambiguous-yet-easy gesture I can think of.
I personally despise gestures that require menu navigation. I'm impatient. I like things like "press and hold button one with the left index finger, press and release the right button with the right index finger three times, press it a fourth time and hold it, then press and release the left button two more times and release the right button" (just to give an example of some hypothetical multi-shifted multi-click gesture you could do with two hard buttons), because they're self-clocking and you can execute them as quickly as your muscle memory can actuate the buttons. I hate having to stop, look at the screen, touch something, wait, touch again, wait, wait, wait, and complete a gesture. I grew up triggering Mortal Kombat fatalities that involved 17 discrete key gestures within 800 milliseconds, and miss the old fashioned immediacy of hardkeys and muscle-memory instantaneous gestures.
Because most people learn that in kindergarten, whereas aside from Android code names are typically more or less random?
I do Android development, and I had a look at the SDK and emulator when it was released last night. I created an emulator and was testing my applications out on it.
The first thing I noticed is that there are more help screens. I believe they disappear after first use, but they tell users how to navigate around the phone. Or tablet as it may be - that's probably the biggest thing about ICS, it integrates Gingerbread (smartphones) and Honeycomb (tablets) into one OS. I've been getting the hang of Android layout, and it is not so hard once you get used to it, you just stick with the things they recommend - density-independent pixels, scale-independent pixels, objects sized by width and/or height by fill-parent (fill layout container object is in) or wrap-object (make object only as large as it need be), objects or layout containers being assigned by weight. One trick I learned - I start design with the smallest device - WVGA - a small device with a low number of dots per inch. I do a portrait (device held with more height than width), and if I have time a landscape (device held with more width than height) view. Sometimes that is enough, and those two layouts work from the smallest to largest devices. Usually it requires a little tweaking, especially Activity classes that make use of buttons. You take the layouts you made and increase text size, increase the distance between objects and other objects, or objects and the edge of the screen. Some people rethink the design, they use Fragments so that where something that would be done on a small screen with ten screen changes with ten different Activity views, is now done with five screen changes with the same ten different Activity views - you just use Fragments to put two or so Activity views per screen. The ICS smartphone/tablet integration will help in that department, although you can do it to some extent already. In fact Fragments were introduced in Honeycomb (the old tablet Android version, before this ICS tablet/smartphone integration), so some of this is just bringing Honeycomb advances back to the smartphone. Another example of this is the Actionbar - over time the Android designers realized it would help UI consistency, ease of programming etc. if they put a bar on top that let people do things (open an email, go to the next page, whatever). So Actionbar was in Honeycomb, now it is in ICS as well. I should mention there is a compatibility package which allows apps to use many (but not all) of these new features on older phones like Gingerbread, Froyo, Eclair etc.
The next thing I noticed when looking at my apps in the ICS emulator is the new Roboto font. It is said to be able to be a good font for everything from a small, low density to a large screen with a high density. Some of my apps use the Android non-default fonts, and the ones I looked at looked most the same, although there may have been small tweaks I did not notice. And Android lets you use your own fonts.
One of my applications runs in the background, doing a database search while updating a progress bar - and while all of this is happening, an ad is often being loaded as well via the web. It seems to be stalling on something in the ICS emulator, I will do some debugging later to see where it is getting stuck. It may be one of those cases where I was doing something wrong but Android allowed it, and they increased the strictness of things. With ICS's use of Fragments, I can probably just load one ad Fragment when my app starts and put that on every screen anyhow.
Regarding source code, I'm sure it will be released. It will be a month or so before you can buy a Samsung Galaxy Nexus anyhow. The sooner the release the better for me, but Android's open nature beats Windows 8 Mango and iOS any day. I can sit at my Linux box, use open source tools to develop everything, and then just push it out to Android Market (or some other market - Android does not lock phones to their store like Apple does). It is beyond me why Apple punishes developers with an app sto
This is from one of the Android devs:
https://plus.google.com/112413860260589530492/posts/DDTKFhiDS9U
"Support for Encryption for Phones
Honeycomb added full-device encryption, but ICS brings it to phones."
Guess they figured it too boring for the launch demo.
Like we did for all Honeycomb release, this is NOT the full source tree for IceCreamSandwich, these are only the GPL parts that are in the SDK (along with a few associated files), and they're not enough to build the whole IceCreamSandwich for a device.
One of the fundamental principles behind the GPL is that if you used GPL parts to make a whole work, then the whole work must also be GPL:
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. "
"These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. "
It's quite obvious that "IceCreamSandwich" is a whole work, and that it contains GPL parts.
Why isn't multi-user support not more important? Maybe not so much in phones, but definitely tablets. If I am at my bro's and my nephew wants to play angry birds on my tablet, I should be able to hand it to him with confidence that he can't see my emails etc. And maybe a limited user (guest) account that can't install/uninstall stuff etc. Why does it have to be like win98 again?!
Working up the ladder, non-copyrighted names: K - Key Lime Pie, L - Lollipop, M - Meringue, N - Napoleon, O - Orange Sherbet, P - Profiterole, Q - Quince or Quiche, R - Rice Pudding, S - Shortcake, T- Tiramisu, can't think of satisfactory "U" terms, "Upside Down Pineapple Cake" is too much of a... err... mouthful.
Lil' Thindime, lilting a lacrimose lament, krashes the kwaint konfines of Kokonino Kounty