• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Galaxy Nexus Watering Hole

My DNA has the exact same issue. Although numerous updates and new sim card seems to have relieved me from the majority of the occurrences.

Hmm... Well, I called Motorola and they said to clear cache and get a new SIM. If it happens after that they'll replace. Probably stop by AT&T this afternoon and get a new SIM.
 
Upvote 0
I hear it's also a dalvik issue. For some reason, it's a bottleneck on Android devices, and it's why ROM'ers are always told to wipe it when flashing anything new. I guess iProducts don't have the same problem.

The Dalvik cache is a lookup table that lays down the association rules between apps.

The Dalvik is the virtual machine that all apps run within.

You wipe the Dalvik cache so that things don't get connected improperly - example I've actually seen is the microphone on the keyboard launching an app not related to voice recognition.

The main cache, not the Dalvik, along with misbehaving apps are the cause of lag creeping in over time.

A factory data reset clears all of it.

Slightly surprised that didn't work for you, so it indicates that if the lag returned after you reinstalled apps, then you have some app(s) misbehaving. If the lag was there after the factory data reset and it's wasn't there when new, then that indicates that the hardware has degraded.

The Dalvik isn't a bottleneck, it's just a major component of the operating system.
 
Upvote 0
The Dalvik cache is a lookup table that lays down the association rules between apps.

The Dalvik is the virtual machine that all apps run within.

You wipe the Dalvik cache so that things don't get connected improperly - example I've actually seen is the microphone on the keyboard launching an app not related to voice recognition.

The main cache, not the Dalvik, along with misbehaving apps are the cause of lag creeping in over time.

A factory data reset clears all of it.

Slightly surprised that didn't work for you, so it indicates that if the lag returned after you reinstalled apps, then you have some app(s) misbehaving. If the lag was there after the factory data reset and it's wasn't there when new, then that indicates that the hardware has degraded.

The Dalvik isn't a bottleneck, it's just a major component of the operating system.
This explanation popped up on Reddit a few weeks back, which is quite interesting.

It's going through each of your apps and hot spotting portions of them to native code. These files reside in the Dalvik cache. If you want to verify the process, delete the contents of your Dalvik cache and reboot. The O/S will rebuild the cache each and every time.
 
  • Like
Reactions: EarlyMon
Upvote 0
If the lag was there after the factory data reset and it's wasn't there when new, then that indicates that the hardware has degraded.

Thanks for that explanation, Early!

I DID have some lag even from day 1 out of the box. For example, I'd press the home or power button when it was asleep, and it would take a good 2 or 3 seconds to wake.

But other things started lagging as the days went by. That would be ridiculous if it was hardware degradation after such a short time.

So in your opinion, why do iOS devices seem to have extremely little to no lag in comparison with Android devices?
 
  • Like
Reactions: EarlyMon
Upvote 0
Thanks for that explanation, Early!

I DID have some lag even from day 1 out of the box. For example, I'd press the home or power button when it was asleep, and it would take a good 2 or 3 seconds to wake.

But other things started lagging as the days went by. That would be ridiculous if it was hardware degradation after such a short time.

So in your opinion, why do iOS devices seem to have extremely little to no lag in comparison with Android devices?
Here's an interesting read (with some other links) if interested.

Are programs written in Java for Android slower than equivalent written in C embedded into Objective-C for iOS? - Stack Overflow
 
  • Like
Reactions: EarlyMon
Upvote 0
This explanation popped up on Reddit a few weeks back, which is quite interesting.

Yeah. No.

That's a grotesque attempt at describing one optimization.

The part about the Dalvik cache being recreated at boot up is true but poorly written.

When you wipe the Dalvik cache, commonly called wiping the Dalvik, then it will be built properly on boot up.

That's why you can do the wipe in the first place.

Android = embedded real-time Linux operating system + the Dalvik Virtual Machine + apps that run in the Dalvik and use Linux system services.

If you have a Java app and you want to run it on your pc, you have to have to have the Java VM installed because it runs inside that.

Java apps for us pick up some resources and get placed into a container called an apk - and an apk is very much like a zip file.

Those apps then run inside the Dalvik.

Native apps in Android have the main portion wrappered and that runs inside the Dalvik.

But I think that you know all of this as you've developed apps, so I'm not sure what you found interesting in your reddit quote.

The Dalvik is a sophisticated stack engine whose details can be easily found and understood more quickly if you're familiar with stack engines. They've been around for decades.
 
Upvote 0
Yeah. No.

That's a grotesque attempt at describing one optimization.

The part about the Dalvik cache being recreated at boot up is true but poorly written.

When you wipe the Dalvik cache, commonly called wiping the Dalvik, then it will be built properly on boot up.

That's why you can do the wipe in the first place.

Android = embedded real-time Linux operating system + the Dalvik Virtual Machine + apps that run in the Dalvik and use Linux system services.

If you have a Java app and you want to run it on your pc, you have to have to have the Java VM installed because it runs inside that.

Java apps for us pick up some resources and get placed into a container called an apk - and an apk is very much like a zip file.

Those apps then run inside the Dalvik.

Native apps in Android have the main portion wrappered and that runs inside the Dalvik.

But I think that you know all of this as you've developed apps, so I'm not sure what you found interesting in your reddit quote.

The Dalvik is a sophisticated stack engine whose details can be easily found and understood more quickly if you're familiar with stack engines. They've been around for decades.

I'm a mid-level programmer and you lost me on that Early, lol. Probably because I'm out of practice though...
 
  • Like
Reactions: EarlyMon
Upvote 0
Yeah. No.

That's a grotesque attempt at describing one optimization.

The part about the Dalvik cache being recreated at boot up is true but poorly written.

When you wipe the Dalvik cache, commonly called wiping the Dalvik, then it will be built properly on boot up.

That's why you can do the wipe in the first place.

Android = embedded real-time Linux operating system + the Dalvik Virtual Machine + apps that run in the Dalvik and use Linux system services.

If you have a Java app and you want to run it on your pc, you have to have to have the Java VM installed because it runs inside that.

Java apps for us pick up some resources and get placed into a container called an apk - and an apk is very much like a zip file.

Those apps then run inside the Dalvik.

Native apps in Android have the main portion wrappered and that runs inside the Dalvik.

But I think that you know all of this as you've developed apps, so I'm not sure what you found interesting in your reddit quote.

The Dalvik is a sophisticated stack engine whose details can be easily found and understood more quickly if you're familiar with stack engines. They've been around for decades.

I understood most of that and have a decent understanding of what goes on under the hood from doing development, a decent amount of reading and having a background in Unix.

I guess the part I found interesting is that "...hot spotting portions of them to native code.", which based on your above I am not sure it is true or not.
 
  • Like
Reactions: EarlyMon
Upvote 0
Morning y'all!

Look, I'm no app dev or anything like that but here's the thing: iOS devices may not show the same lag over time like a cheap Nexus 7 might, but it is certainly not the fast, lag free, operating system some make it to be.

Been using this iPhone 5 now for a month and the way I would describe the experience is rhythmic. The OS keeps a certain rhythm that is consistent and familiar. And while that rhythm isn't slow, it isn't as fast as the Nexus 4 I was using before it. The Nexus did just about everything faster. But when one task doesn't go at the same speed as the rest, we call it lag.

Now in Han's case, it sounds like deadlocks from Android 4.3 combined with TouchWiz causing freezes and terribly noticeable lag. I experienced deadlocks on 4.3 with my Nexus.

Anyway, hope that made some kind of sense.

Now Google, can we just get on with it and release the Nexus 5 already?

Thanks,

jmar
 
Upvote 0
Unfortunately not yet - next update will include it though.

Only insight I have is downloads & installs.

Same here, was wondering if you had tried it. I may update my app to add it. I cracked the 9k active installs last week and should hit 10k before November is over. Just curious where my traffic is coming from.
 
Upvote 0
I understood most of that and have a decent understanding of what goes on under the hood from doing development, a decent amount of reading and having a background in Unix.

I guess the part I found interesting is that "...hot spotting portions of them to native code.", which based on your above I am not sure it is true or not.

There's been an optimization movement afoot since last year called Linaro.

It's been making its way into Android bit by bit, you can expect to see custom roms compiled with a bit of it already.

The following video shows it being unleashed for the first time back in 2012.


You may note with interest that the processor chosen at the first target for that demonstration is the OMAP 4430 - reminder: the one in the GNex, so now we're topical to that as well as Android.

You all heard me talk about the power of that processor in the pre-release thread.

That video finally illustrates what I meant was possible. From how Google talked back in 2011, that's the performance we all expected anyway.

The next stage in optimization, rumored for Android 4.4, is to transform some of the Java code into native code.

The optimizations there are more about time lost for context switching than native vs. Java.

That work was demonstrated in 2010 but we learned only recently (10/22) that Google has been busy for a year buying that technology and has finally done it.

Google's FlexyCore purchase could mean a smoother Android

The samples from 2010 have been pulled by Google now.

THAT story is the source of the latest belief that there's something converting Java out of the Dalvik and into native code.

It hasn't been deployed before and it's pure speculation if any of it is in 4.4.

Personally, I don't believe at this juncture that it's in there yet.


The respondents there were upset that the question was wrong.

I have to agree because it's blending the difference in languages and operating systems and trying to make it a language question.

The apples to apples comparison for starters is how does Java compare to native code on Android?

Answer below:

Cool. So I got a question, are c++ apps run through dalvik as well or is that native? My assumption is its native but I want to confirm it.

Not so fast. :)

Warning - detailed tech follows. If bored, skip to the TL/DR at the end.

Android NDK | Android Developers

Once upon a time, that page used to say that native apps ran inside the Dalvik.

If you Google "Android NDK" really quickly you can see a cached version that says that.

The truth is more complicated -

android - Where exactly does NDK native code execute - Stack Overflow

For non-programmers, I'll save you the trouble on both links -

Everything is tied to the Dalvik Virtual Machine.

There are no *great* performance benefits to c++ native code unless you have a special case of something being computationally intense, according to Google.

If you want to see for yourself, check out "CF-Bench"

https://play.google.com/store/apps/details?id=eu.chainfire.cfbench

But be sure to read the app description, this is not your typical benchmark.

While not intended to rank phones, really, this is the only benchmark that seems to match my experience comparing phones when I consider just the Java predictions, matching the green bars in the second screen shot.

View attachment 62717
View attachment 62718

Notice that there aren't Java tests for everything that there's a native test for - some things just are not done by an app, they're done by the underlying software services - and those are ALL native code.
Warning - GPU for gaming, screen management cores (surprise, it may not be your GPU), NEON or equivalent for media, network throughput and whole big bunch of other things that matter are not tested.

~~~~~~~~~~~~~


TL/DR -

Native apps are good for the rare cases of number crunching.

The real benefit is if you already have a lot of c++ or c code that you trust and don't want to re-write in Java.

PS - this thread now in the Things To Know About Android sticky, thanks to El Presidente. :)

Should probably clarify.

Some articles call apps that come with your phone "native" - we're talking about something else - the programming language.

Neither Firefox nor Unity games come with anyone's phone, so far as I know, but both are native apps in the programming sense.

By the way -

Unity - iOS and Android mobile game development

And -

Does Unity use Android NDK?

Given that unity started out with a large, trusted code base from iOS, that second bit sounds more like marketing than technology to me.

So - it's not huge, just taking the native code bit.

However, some things DO benefit from that optimization.

Here's a video showing the difference Flexycore makes on a TI development phone using the - wait for it - OMAP 4430 found in the GNex.


So that leaves the final difference - Android vs. iOS and that's Han's question.

Thanks for that explanation, Early!

I DID have some lag even from day 1 out of the box. For example, I'd press the home or power button when it was asleep, and it would take a good 2 or 3 seconds to wake.

But other things started lagging as the days went by. That would be ridiculous if it was hardware degradation after such a short time.

So in your opinion, why do iOS devices seem to have extremely little to no lag in comparison with Android devices?

Good news! :)

I come bearing few opinions and many facts.

The first fact is that Android lag and fluidity vary a lot by user within a given device model and that has a simple explanation due to two other facts - not all apps are created equally and Android is rich in configuration options, both affect the end result.

So why has iOS been more fluid, even on lesser, slower processors with less ram?

First fact - prior to iOS 7, their multitasking has been slim - it's cooperative multitasking while ours is preemptive multitasking.

Focus on that fact above - all blessings and curses flow from that single design difference between iOS and Android and that's the big fact.

If you ever ran Windows 95, then you've run cooperative multitasking before. Modern Windows is preemptive, so is OS X, Linux and therefore Android.

In a cooperative multitasking system, the foreground app takes over nearly everything. You know that from Win95. Curse iOS.

And if that's all your processor has to support, then it can do a rocking a job and not have to be a beast processor. Blessing iOS.

Android can't be that way because it's based on Linux. Curse Android.

But that architecture lets Android have a lot more flexibility and configurations. Blessing Android.

With me so far?

So the first outcome of that difference is -

  • when Apple changes processors significantly, apps have to be redone and re-optimized and then re-aquired by the end user when available
  • not Android, when dual core and then quad core hit we didn't need all need new apps (many of you may remember my assurances on that from the pre-release thread and if you do remember that, then you know from experience I was sharing a fact then) - the architecture makes it so apps don't care
  • Advantage Android for ease of platform choice by users, advantage iOS for highest level of per app optimization
Finally, iOS allows some apps to play a trick called GPGPU - general purpose processing using GPU cores that are available.


That's another old trick, I used to write GPGPU applications in assembly for HP workstations back in the early 80s.


That code is not transportable and not something you really want to go for in Linux.


But - a number of iOS apps do that. I know in particular that their pro media editing app used by pro photographers do exact that.


And that's attractive in the iOS world because what Apple processors lack in CPU power, they make up in their GPUs. Apple's always been media centric and since the change to OS X way over a decade ago, they've been focused on media (introducing the iPhone, our best iPod ever - look it up, that's was Steve's keynote speech when they launched it) and PDFs.


I mention that as a point of interest to Han - when OS X hit, it took nothing to convert anything to a PDF, the underlying tech was built into the desktop itself. Windows users had to buy Adobe Distiller back then and Linux users were converting postscript into PDF by hand in those days.


But the simple version of all this comes down to what you already know:



  • Apple chooses your hardware for you so you don't make the wrong choice and all of the software exploits that
    • Within the limits of the closed choices available
      • You cannot send me a youtube that I cannot play on my Android phone (except for where I'll respect copyright restrictions).
      • I can send a youtube that no iOS user will ever see until they get home.
  • Android lets you choose any hardware and then adopts two burdens:
    • Android responds better to better processing and memory resources
    • It's up to Android to produce competitive optimizations because the architecture says - don't force that entirely onto the app developer


But in the really advanced media processing apps - raw digital image processing, soundboard mixers and PDF markup apps as well as a number of games - iOS is still winning because their optimization techniques allow them to.


Each iteration of Android is bringing new optimization techniques that is allowing the gap in those areas to be closed.


^Those are all facts.


I promised some opinions as well, here they are -


I think that eventually all of the scales will tip in Android's favor..


I think that if Google coorporate stops focusing on that and continues on their Apple-like path lately adopted to bring you into a closed world that they control for profit, then Android will become closed and a new open competitor will emerge. See me on the forum for that new platform when the day comes (and it's not going to be Ubuntu or Firefox - I don't know what it'll be, but it won't be those).


There is no perfect device or mobile operating system. Get what works for you and for your needs, whatever it may be.


These companies are not our friends, they're our suppliers. If we buy what we really like and need then if they're smart, they'll continue to improve their offerings to us to compete for our money.


Bling bling, dollar dollar bill, y'all. - Wu Tang Clan Financial


Advantage - us.
 
Upvote 0
There's been an optimization movement afoot since last year called Linaro.

It's been making its way into Android bit by bit, you can expect to see custom roms compiled with a bit of it already.

The following video shows it being unleashed for the first time back in 2012.


You may note with interest that the processor chosen at the first target for that demonstration is the OMAP 4430 - reminder: the one in the GNex, so now we're topical to that as well as Android.

You all heard me talk about the power of that processor in the pre-release thread.

That video finally illustrates what I meant was possible. From how Google talked back in 2011, that's the performance we all expected anyway.

The next stage in optimization, rumored for Android 4.4, is to transform some of the Java code into native code.

The optimizations there are more about time lost for context switching than native vs. Java.

That work was demonstrated in 2010 but we learned only recently (10/22) that Google has been busy for a year buying that technology and has finally done it.

Google's FlexyCore purchase could mean a smoother Android

The samples from 2010 have been pulled by Google now.

THAT story is the source of the latest belief that there's something converting Java out of the Dalvik and into native code.

It hasn't been deployed before and it's pure speculation if any of it is in 4.4.

Personally, I don't believe at this juncture that it's in there yet.



The respondents there were upset that the question was wrong.

I have to agree because it's blending the difference in languages and operating systems and trying to make it a language question.

The apples to apples comparison for starters is how does Java compare to native code on Android?

Answer below:


So - it's not huge, just taking the native code bit.

However, some things DO benefit from that optimization.

Here's a video showing the difference Flexycore makes on a TI development phone using the - wait for it - OMAP 4430 found in the GNex.


So that leaves the final difference - Android vs. iOS and that's Han's question.



Good news! :)

I come bearing few opinions and many facts.

The first fact is that Android lag and fluidity vary a lot by user within a given device model and that has a simple explanation due to two other facts - not all apps are created equally and Android is rich in configuration options, both affect the end result.

So why has iOS been more fluid, even on lesser, slower processors with less ram?

First fact - prior to iOS 7, their multitasking has been slim - it's cooperative multitasking while ours is preemptive multitasking.

Focus on that fact above - all blessings and curses flow from that single design difference between iOS and Android and that's the big fact.

If you ever ran Windows 95, then you've run cooperative multitasking before. Modern Windows is preemptive, so is OS X, Linux and therefore Android.

In a cooperative multitasking system, the foreground app takes over nearly everything. You know that from Win95. Curse iOS.

And if that's all your processor has to support, then it can do a rocking a job and not have to be a beast processor. Blessing iOS.

Android can't be that way because it's based on Linux. Curse Android.

But that architecture lets Android have a lot more flexibility and configurations. Blessing Android.

With me so far?

So the first outcome of that difference is -

  • when Apple changes processors significantly, apps have to be redone and re-optimized and then re-aquired by the end user when available
  • not Android, when dual core and then quad core hit we didn't need all need new apps (many of you may remember my assurances on that from the pre-release thread and if you do remember that, then you know from experience I was sharing a fact then) - the architecture makes it so apps don't care
  • Advantage Android for ease of platform choice by users, advantage iOS for highest level of per app optimization
Finally, iOS allows some apps to play a trick called GPGPU - general purpose processing using GPU cores that are available.


That's another old trick, I used to write GPGPU applications in assembly for HP workstations back in the early 80s.


That code is not transportable and not something you really want to go for in Linux.


But - a number of iOS apps do that. I know in particular that their pro media editing app used by pro photographers do exact that.


And that's attractive in the iOS world because what Apple processors lack in CPU power, they make up in their GPUs. Apple's always been media centric and since the change to OS X way over a decade ago, they've been focused on media (introducing the iPhone, our best iPod ever - look it up, that's was Steve's keynote speech when they launched it) and PDFs.


I mention that as a point of interest to Han - when OS X hit, it took nothing to convert anything to a PDF, the underlying tech was built into the desktop itself. Windows users had to buy Adobe Distiller back then and Linux users were converting postscript into PDF by hand in those days.


But the simple version of all this comes down to what you already know:



  • Apple chooses your hardware for you so you don't make the wrong choice and all of the software exploits that
    • Within the limits of the closed choices available
      • You cannot send me a youtube that I cannot play on my Android phone (except for where I'll respect copyright restrictions).
      • I can send a youtube that no iOS user will ever see until they get home.
  • Android lets you choose any hardware and then adopts two burdens:
    • Android responds better to better processing and memory resources
    • It's up to Android to produce competitive optimizations because the architecture says - don't force that entirely onto the app developer


But in the really advanced media processing apps - raw digital image processing, soundboard mixers and PDF markup apps as well as a number of games - iOS is still winning because their optimization techniques allow them to.


Each iteration of Android is bringing new optimization techniques that is allowing the gap in those areas to be closed.


^Those are all facts.


I promised some opinions as well, here they are -


I think that eventually all of the scales will tip in Android's favor..


I think that if Google coorporate stops focusing on that and continues on their Apple-like path lately adopted to bring you into a closed world that they control for profit, then Android will become closed and a new open competitor will emerge. See me on the forum for that new platform when the day comes (and it's not going to be Ubuntu or Firefox - I don't know what it'll be, but it won't be those).


There is no perfect device or mobile operating system. Get what works for you and for your needs, whatever it may be.


These companies are not our friends, they're our suppliers. If we buy what we really like and need then if they're smart, they'll continue to improve their offerings to us to compete for our money.


Bling bling, dollar dollar bill, y'all. - Wu Tang Clan Financial


Advantage - us.

Early,

Kudos on the Wu Tang reference! :D

I agree with everything you said (who wouldn't?).

Really looking forward to getting back on Android with the Nexus 5 and Android 4.4 (technically I haven't left because my Nexus 7 (2012) is still rocking with AOKP!). Hopefully the N5 camera is as amazing as this one on the iPhone. Either way my money is ready!

@google: #mybodyisready
 
  • Like
Reactions: EarlyMon
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones