x PhoneArena is hiring! Reviewer in the USA
  • Options
    Close






Did you know: 5 interesting facts about Android L

0. phoneArena 20 Jul 2014, 10:02 posted on

Google unveiled its brand new version of Android at Google I/O nearly a month ago, and that makes for more than enough time for us to get acquainted…

This is a discussion for a news. To read the whole news, click here

posted on 20 Jul 2014, 19:06 3

55. yowanvista (Posts: 340; Member since: 20 Sep 2011)


Educate yourself before posting crap.
http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l

posted on 20 Jul 2014, 19:34

56. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)


Oh, my bad. They are also named differently.

But beside that, I repeat, the same crap.

Google is trying to make you believe ART is something advanced,
but in reality, it's all about dealing with the overheads in a different way.
The joke is however, these overheads aren't existent on native platforms to start with.

Educate yourself before posting crap.

posted on 20 Jul 2014, 20:48

58. Arte-8800 (banned) (Posts: 4562; Member since: 13 Mar 2014)


There are lots of weird things in both APIs. I personally find it hard to think up the same names for methods that the NextStep team did (the core of iOS and the reason everything starts with NS). When I want to stop a timer in Android I call stop() when I want to stop one in iOS I call invalidate. Which one makes more sense to you? I can find examples where iOS is better than Android just as easily.
Google needs to improve the framework. Animations could be cleaner and easier, the UI framework needs work too. I want more controls baked in. I hate the original calendar picker. Not a huge fan of the slot machine spinner on iOS as it was so huge. Newer Android versions are much improved.
Apple needs a lot of improvements too. Look how long it took them to support something like regular expressions they should have had from the start. They have no support for modal UIAlertViews which can really suck. The whole delegate methodology for UIAlertViews makes things a big mess when you have multiple of them in a single piece of code. Who the heck wants to deal with button indexes? You reorder or change the visible buttons and it is all out of whack.
Xcode needs some more features or maybe plug-in support so people can add things they need. It is an OK IDE but is missing a lot of features I have really gotten used to in Eclipse. AppCode is a huge help in this area and I use that for balls to the wall code editing and use Xcode when I need Interface Builder, Story Boards and Core Data manipulation.
Coming from PC development I like the layout managers of Android for the most part. You can come up with a couple of layouts that work nicely on a number of devices. I see a number of iOS apps that are locked into portrait as no one wants to even do a second layout for landscape.
iOS is locked into a few sizes. Sure, that makes is easier on the designer but for Apple to do a new screen size things are going to break since there is so much hard coded to the current sizes. They lost out on future flexibility. That will generally come and bite you. A bit of the pain was felt on the larger iPhone 5.
Developers and designers can do a better job on Android. Excuses need to stop being made. Google does back port new APIs which is nice. Apple pushes you into the future via OS upgrades and does not back port anything. ARC sure as hell makes life a lot easier. I am excited to try out the new Auto Layout.
We need them both around to push each other.

posted on 20 Jul 2014, 20:56

59. tedkord (Posts: 12217; Member since: 17 Jun 2009)


Ahead of time compiling removes the overhead of JIT.

posted on 20 Jul 2014, 11:34 1

21. dexter_jdr (Posts: 1163; Member since: 28 Jun 2012)


i did not know that 5 facts = 7 pictures.

posted on 20 Jul 2014, 13:47 1

37. Berzerk000 (Posts: 4275; Member since: 26 Jun 2011)


The last 2 are labelled as assumptions.

posted on 20 Jul 2014, 12:06

23. hurrycanger (Posts: 1572; Member since: 01 Dec 2013)


I just feel like Google is taking their time working with another company to use their product's name for the next Android. Just like Kit Kat.

posted on 20 Jul 2014, 12:07

24. ChooseGoose (Posts: 5; Member since: 09 Jul 2014)


The second image has Key Lime Pie instead of Kitkat...

posted on 20 Jul 2014, 12:21

25. hurrycanger (Posts: 1572; Member since: 01 Dec 2013)


yea.. it's an old image. Google did make it Android Key Lime Pie though, and later changed it to Kit Kat.

posted on 20 Jul 2014, 12:29

26. guest (Posts: 338; Member since: 13 Jun 2012)


All of Intel's processors are 64 bit and I am sure they would give Google a sweet price just to break into the Android platform. Oh and they are already shipping.

posted on 20 Jul 2014, 13:18 1

30. ayephoner (Posts: 850; Member since: 09 Jun 2009)


kit kat is made by herhsey's. herhsey's only L candy is the caramels named Lancaster. if you weren't paying attention to candy over the last year, herhsey announced this brand last fall and it came out in the winter. this wasn't too long after hershey and google released kit kat.

i'm not sure if anyone else has thought about this, or put it out there, but i'm thinking android 5.0 will be "android lancaster." you (maybe) heard it here first.

posted on 20 Jul 2014, 13:21

31. ayephoner (Posts: 850; Member since: 09 Jun 2009)


http://www.candywarehouse.com/assets/item/large/Lancaster-Caramel-logo21.jpg

i could totally see the android robot stamped out in that vanilla caramel pattern for the new statue.

posted on 20 Jul 2014, 14:35 1

40. chromoid (Posts: 19; Member since: 03 Oct 2013)


Kit Kat is made by nestle. Hersheys has a license to make it in the us.

posted on 20 Jul 2014, 14:48 1

43. ayephoner (Posts: 850; Member since: 09 Jun 2009)


the deal with google was with hershey's as well as nestle. i'm just making a guess anyways, but it makes sense to me.

http://www.mercurynews.com/business/ci_24004511/google-names-new-android-version-kit-kat-deal

posted on 20 Jul 2014, 13:45

34. lolatfailphones (Posts: 203; Member since: 08 Apr 2013)


Why is this news "Hot"?

posted on 20 Jul 2014, 17:59 1

53. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)


Cause all the Androtakus gathered here for a preemptive strike on me and the truth.

posted on 20 Jul 2014, 21:40

60. lolatfailphones (Posts: 203; Member since: 08 Apr 2013)


Lol I was like..WTF slow news arena?

posted on 20 Jul 2014, 14:17

39. mas11 (Posts: 1034; Member since: 30 Mar 2012)


As someone that builds PCs as a hobby, I don't understand what the big deal is when it comes to 64-bit. All 64-bit really does is allow the system to use 4+ GB RAM.

posted on 20 Jul 2014, 14:41 1

41. chromoid (Posts: 19; Member since: 03 Oct 2013)


That is not the only thing 64 bit cups offer
One of many is a larger instruction bus that allows longer instruction sets to be passed through the cpu.

posted on 21 Jul 2014, 09:34

71. ArmDeveloper (Posts: 2; Member since: 20 Jul 2014)


There's no such thing as "instruction bus".

Both 32-bit (recent ARMv7, like Cortex A7/A15, etc.) and 64-bit ARM CPUs (like Cortex 53/57) can process 128 bits per single NEON instruction.

A common misconception is that AArch64 could intrinsically process more data per clock cycle than before. It's still limited to processing *128 bits* per single NEON instruction, for example 4x 32 bit packed floats "at a time", just like earlier 32-bit ARM chips. Of course, it's a different matter how many instructions are actually issued and processed per clock cycle. At least some ARMv7 CPU implementations actually take 2 cycles to process a single simple 128-bit NEON instruction, such as vector addition. Such previous generation "half issue" 32-bit CPUs could only really process 64-bits per clock cycle. Of course nothing prevents from implementing a similar "half issue" 64-bit ARMv8 CPU...

Amount of processing done per clock cycle does not depend on architecture, rather on particular chip implementation.

posted on 20 Jul 2014, 22:01

62. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)


True, the benefit of 64bit computing is quite significant, but rather situational.

While what you are saying might be valid on x86, it's different on ARM.
It absolutely needed a new instruction set in order to raise the IPC beoynd that of the CA15's.
And there was no reason for this to remain a 32bit one. Et voilà, aarch64 is born.

posted on 20 Jul 2014, 23:43

64. ArmDeveloper (Posts: 2; Member since: 20 Jul 2014)


As someone who builds PCs as a hobby, you should know that 32-bit systems do not limit amount of addressable RAM to 4 GB. Operating systems do.

32-bit can address just as much physical RAM as 64-bit. There's of course a well known consumer operating system vendor that has limited their OS to just 4 GB on 32-bit platforms. But that's not a technical limitation, just a marketing one (or something similar).

This applies to x86 CPUs as well as to newer 32-bit ARM CPUs.

posted on 20 Jul 2014, 16:44

47. corporateJP (Posts: 2431; Member since: 28 Nov 2009)


Dwayne said: "Just Bring It"...

posted on 20 Jul 2014, 17:11

48. antmiu2 (Posts: 322; Member since: 19 Jun 2011)


Android L is the first ground-up redesign since Android 4.0 ... no its much like kit kat with a theme on it

posted on 20 Jul 2014, 21:48

61. tedkord (Posts: 12217; Member since: 17 Jun 2009)


No, it isn't. It changes a large part of the way Android works, with a change from JIT to AOT compiling.

posted on 20 Jul 2014, 22:07

63. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)


And what Google doesn't want you to know : the Dalvik vs ART graph is only valid for Nexus. Qualcomm's 32bit Dalvik JIT beats the hell out of Google's 64bit ART.

posted on 21 Jul 2014, 00:36

65. joey_sfb (Posts: 5991; Member since: 29 Mar 2012)


Why bother? Opinion are like ass holes. Everyone has one.

Android is still preferred mobile OS after switching over from iOS and I will use it till another better choice appear. More than ever I preferring Xiao Mi Redmi Note over my Samsung Note 3. I like MIUI interface over Touchwiz.

For Xiao Mi Ex-Samsung user, try out Smart stay EX works as well as my Samsung Note.

Still I will buy Note 4 when its available.

posted on 21 Jul 2014, 05:01

70. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)


It's not my opinion but a fact.

Google's JIT sucks. That's the only reason that they got much gain through a less lousy job.

And here is my opinion :
They should be ashamed instead of presenting this graph proudly.

posted on 21 Jul 2014, 02:14

67. tedkord (Posts: 12217; Member since: 17 Jun 2009)


You're talking about the QC optimized DALVIK (which is very good) vs. the KitKat version of ART, which is a beta feature (and isn't 64bit). Also, the QC DALVIK isn't useful for non-QC chipsets.

The newer Android L dev preview ART is showing very solid performance and battery gains, up to 2-3X speed improvements.

It doesn't matter how much you cry and fuss, Android is here to stay.

posted on 21 Jul 2014, 04:55 1

69. JakeLee (banned) (Posts: 1021; Member since: 02 Nov 2013)


You forgot to mention "according to Google", "allegedly"

And you also forgot that I have access to the 64bit PDK plus developer board.

Optimization is a rather ungrateful job :
If you can achieve very much through optimizations, it just means the orignial was a lousy job to start with.

And that's Google's JIT that massively sucks while the new ART is a halfway decent one, nothing else here.

And again, vendors like Qualcomm will optimize ART, but the performance gain over their Dalvik JIT will be marginal at best.

All these bells and whistles around ART aren't justified.

Java sucks 31 balls to start with.

* Some comments have been hidden, because they don't meet the discussions rules.

Want to comment? Please login or register.

Latest stories