Database Info

[Q] How are apps using dual core in the new android phones?

Hi, the way I see it, android (especially the newer versions) are capable of distributing several processes over the dual cores. Apps however don't utilise both cores.
Another question: what kind of apps would benefit from using both cores? I could imagine that heavy games and home launchers could benefit from using both cores.
Are there tools available for android that enable multithreading apps? And what are the average prices of app development tools?
Im currently working in Java, but how do most people write Android apps?
Edit: Just found some information that confirms my thoughts on how android uses parallel structures, but this still leaves open my other questions:
"Android 2.2 already takes advantage of multicore. Anything that multitasks and multithreads already takes advantage of multicore. But this exploitation is a matter of degrees.
Android 2.3 takes further advantage of the multicore, because unlike Android 2.2, 2.3's file system is multithreaded one, not single threaded. When it comes to file I/O or database searches. 2.3 will be a lot faster.
Android 2.4 or 3.1 as rumored to be, will take even greater advantage of multicores with further "architecting" parts of the OS to use more multithreads."

thanks .....

Does the 1ghz processor on WP7 fully utilised?

Can anyone with experiences or skillful developers answer my question?
every time when I opening up an application which i downloaded from the marketplace(non-stock apps),the speed was like i open an app on my iphone 3g,laggy and sluggish.
Honestly,the wp7 experience is not that great for me CURRENTLY and I don't have much money like M$,if not I could buy a second gen wp7 device.So,is it possible mango will fix everything up?or just the 1ghz processor is not good enough to run wp7?
I would prefer windows mobile 6.5 with wp7 animation&transition,then i'm good to go.

now this could be a novel question
but could it be the application itself? you even said native programs are smooth....

yea,true,native apps are buttery smooth.However,in other apps are so laggy.any solution for these problems?is it related to the APIs or the OS itself?

It's related to developers running business and dal code on the ui thread.
Give it time, devs will learn how to do it properly, especially with the new tools coming in VS soon.
1Ghz is plenty, and barely relative.
Is the Xbox fast enough? Of course, even 5 years after - because devs know how to utilise it properly, and build FOR the platform, not blame the platform for their inefficient code.

sylau90 said:
Honestly,the wp7 experience is not that great for me CURRENTLY and I don't have much money like M$,if not I could buy a second gen wp7 device.So,is it possible mango will fix everything up?or just the 1ghz processor is not good enough to run wp7?
Click to expand...
Click to collapse
Mango will fix a lot of it, developers need to fix some of it as well.
http://www.mobiletechworld.com/2011...overview-32bit-color-support-better-controls/

thanks mate @PG2G,thats really helpful and looks promising...can't wait for mango

domineus said:
now this could be a novel question
but could it be the application itself? you even said native programs are smooth....
Click to expand...
Click to collapse
Microsoft and oems cam use native code. Thirsting party developers cannot. That is why stock apps perform perfectly but third party apps suffer.
Developers can fix it by stripping out all the eye candy from their apps but then your left with a modern day textual user interface...
I hope they open up some native apps soon. Even in desktop apps the performance advantage odd an mfc oems or Delphi app is immediately apparent compared to their .net counterparts, even with beastly hardware.
Better hardware and os-level optimization will help the situation soon, though...
Sent from my SGH-T959 using XDA App

3rd party apps are all written in .NET managed code. When the app first loads, it needs to be compiled into native code and also instantiate inside a SliverLight player. Both take extra processing power and time compared to native apps that need to do neither tasks. I'm sure MS will continue to optimize the speed of JIT and SilverLight player. It will never match the native app load speed but it also won't bring down the entire OS if something goes wrong like the native apps potentially could do.

foxbat121 said:
3rd party apps are all written in .NET managed code. When the app first loads, it needs to be compiled into native code and also instantiate inside a SliverLight player. Both take extra processing power and time compared to native apps that need to do neither tasks. I'm sure MS will continue to optimize the speed of JIT and SilverLight player. It will never match the native app load speed but it also won't bring down the entire OS if something goes wrong like the native apps potentially could do.
Click to expand...
Click to collapse
.NET can precompile assemblies. That is what NGen does on the desktop. I'd find it quite odd if all of the base OS assemblies (entire .NET framework, etc.) isn't NGen'd on the phone. In fact, it would be pretty amatuer for Microsoft not to do that.
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead using the just-in-time (JIT) compiler to compile the original assembly.
Click to expand...
Click to collapse
Issues at play:
1. Older SoC with Older GPU in it: The phones would obviously perform better with a newer 1GHz Snapdragon or TI OMAP CPU. A Hummingbird would fly (too bad Samsung couldn't use it) with WP7.
2. Overreliance on Managed Code: This will get better as software is optimized more (the base platform) and WP7 users move to newer devices. But Managed Code, while not far behind Native code in many instances, just can't touch Native code in many places. You could develop MFC applications for Windows Mobile. .NET CF applications could not compete with those applications for performance.
3. Resources: Stock Apps do Multi-Task and in many cases you cannot truly exit them. If those apps are in the background eating up resources, then you will get worse performance.
Expanding on that, and of particular interest is RAM. Devices say they have 512 MB RAM but most devices have 128 MB dedicated to the GPU. The system and applications cannot use that for general purpose tasks. So while you may think you have 512 MB RAM, you really only have a configuration equivalent to 384 RAM with a 128 MB Graphics card in your phone. 128 MB is a large percentage of 512 (though a small number), and it can have performance implications on the device.
This is why HTC added an extra 64 MB RAM in their HD2/7 devices. The HD2/HD7 have 576 MB RAM, but 128 MB is dedicated to the GPU, so the system/apps really only has access to 448 MB of that.
4. Module dependency: Native Applications written in something like Visual C++ (MFC) or Delphi/C++Builder (VCL) don't really have that many module dependencies. That's why their load times are ridiculously fast. .NET applications have large module dependency chains and have to load in many cases a lot more libraries. There's a huge difference between loading the C++ Runtime and an MFC Shared Library (assuming the app was NOT statically compiled) and loading the app and having it daisy-chainload 20 different modules into memory.
Not to mention Native Applications can be multi-tasked much better because well written native apps tend to not use as much RAM.
On PCs this is less of a problem these days, since CPUs/RAM and even Hard Drives (SSD, etc.) are so fast and we have tons of RAM. But on phones, all of these factors can have factorably performance implications (excuse the redundancy).
But it is only that bad in certain types of apps - particularly those with long lists and tons of eye candy in the user interfaces. It should get better with updates.
P.S. There are ways to sandbox Native Apps, as well

BlueStacks App player

Hi everyone.
Could anybody compile BlueStacks App Player for Windows RT?
It would be great to use this app on our tablet with Win RT
I use on my laptop (win7) and wish o use on my Surface RT
Official site
Thanx a lot

It would be a great app to have, but seeing that it's not open-source there is about zero chance of it ever getting ported by the community.
Your best bet is to just hope that they (the actual makers of the app) decide to bring it over to RT, which is possible but unlikely.
Search next time; the devs here are up to their ears in requests for closed-source applications and are pretty fed up with it. Sorry.

They've actually already stated that it's coming...

Not explicitly. They hinted at it in a Help forum post, but never confirmed or denied it. And that was months ago.

jtg007 said:
Not explicitly. They hinted at it in a Help forum post, but never confirmed or denied it. And that was months ago.
Click to expand...
Click to collapse
Actually they had listed on their site that they were working on an ARM version.but not sure if they still are. Seems unlikely MS would allow it in the store due to direct competition with the windows store.

guitar1969 said:
Actually they had listed on their site that they were working on an ARM version.but not sure if they still are. Seems unlikely MS would allow it in the store due to direct competition with the windows store.
Click to expand...
Click to collapse
MS doesn't have a whole lot of control of things outside the Store. They could side-load an app pretty easily.

The vast majority of RT devices aren't "jailbroken" for sideloading arbitrary ARM binaries. Also, remember that RT doesn't (currently) support OpenGL, which means any Android apps/games that use advanced graphics won't work unless BlueStacks write and include an openGL-via-DirectX compatibility layer.

GoodDayToDie said:
The vast majority of RT devices aren't "jailbroken" for sideloading arbitrary ARM binaries. Also, remember that RT doesn't (currently) support OpenGL, which means any Android apps/games that use advanced graphics won't work unless BlueStacks write and include an openGL-via-DirectX compatibility layer.
Click to expand...
Click to collapse
I meant side-loading a Metro app, which can be done by just about everybody.

Cant sideload metro apps without a developers certificate

Derp. Yes, of course sideloading is the obvious way to go about it. Getting the dev license is easy, and yeah BS would have to sign their app, but that's not exactly difficult and their cert doesn't have to be signed by anybody else; it just requires that the end user install the cert before the app if it doesn't already chain to a trusted authority. The appx installer script automates all of that, though.
That said, the OpenGL issue is still there. Don't count on 3D games, at a minimum, working.

Don't forget however, that all of this is pretty much irrelevant right now. The Surface lacks the power to run Bluestacks. On my 6-core 2.3 ghz 6 gigs of ram computer with a great graphics unit, Bluestacks is still relatively slow. Just imagine it on the quad-core 1.4 with 2 gigs of ram that the Surface has. Not to mention it's on ARM, which is considerably less powerful than x86 or x64.

C-Lang said:
Don't forget however, that all of this is pretty much irrelevant right now. The Surface lacks the power to run Bluestacks. On my 6-core 2.3 ghz 6 gigs of ram computer with a great graphics unit, Bluestacks is still relatively slow. Just imagine it on the quad-core 1.4 with 2 gigs of ram that the Surface has. Not to mention it's on ARM, which is considerably less powerful than x86 or x64.
Click to expand...
Click to collapse
I dont think bluestacks is a multithreaded application in which case your 6 cores would be irrelevant and it would be purely down to your 2.3ghz clockspeed, which is not high at all. 6gb of RAM would also be irrelevant as no android app requires that much RAM so it simply wont be needed. GPU, not so sure what happens there, most of the apps I try running dont seem to enable my GPU at all so I am not sure if bluestacks is using software or hardware OpenGL, but then I havent tried any 3d games or anything. It runs ok on my 3.5ghz AMD athlon 2 but its not always as perfect as lets say a nexus 7 tablet running android natively.

I'm admittedly not 100% sure on how BlueStacks works (is it a native x86 DalvikVM, or is it emulating a full ARM system?), but it should be, at least in theory, possible to get it to run as naively as it does on Android by just porting the DalvikVM to Windows RT. That should result in speeds at least similar to a lower end Android tablet (Windows is bigger and has more cruft than the linux kernel that's running the DVM). With some sort of reverse WINE scenario it should also be possible to get a degree of binary compatibility for native libraries/addons.

SixSixSevenSeven said:
I dont think bluestacks is a multithreaded application in which case your 6 cores would be irrelevant and it would be purely down to your 2.3ghz clockspeed, which is not high at all. 6gb of RAM would also be irrelevant as no android app requires that much RAM so it simply wont be needed. GPU, not so sure what happens there, most of the apps I try running dont seem to enable my GPU at all so I am not sure if bluestacks is using software or hardware OpenGL, but then I havent tried any 3d games or anything. It runs ok on my 3.5ghz AMD athlon 2 but its not always as perfect as lets say a nexus 7 tablet running android natively.
Click to expand...
Click to collapse
Sort of, yes. But still, that means the Surface would be way less powerful. Also, my RAM is EATEN by Bluestacks because it's not apps that are the problem to run, it's Android. You're basically loading an entire virtual machine onto your RAM to run, in a program shell, then running Android apps on top of that. So the power of the device does matter... however:
netham45 said:
I'm admittedly not 100% sure on how BlueStacks works (is it a native x86 DalvikVM, or is it emulating a full ARM system?), but it should be, at least in theory, possible to get it to run as naively as it does on Android by just porting the DalvikVM to Windows RT. That should result in speeds at least similar to a lower end Android tablet (Windows is bigger and has more cruft than the linux kernel that's running the DVM). With some sort of reverse WINE scenario it should also be possible to get a degree of binary compatibility for native libraries/addons.
Click to expand...
Click to collapse
Bluestacks would have to run a full emulation of ARM in order to run all apps, right? Because when you install native x86 Android, it runs very few apps from the store, because they aren't compiled for ARM.
Netham45 could be right though that we could kind of make Android run natively, though I'm highly dubious about it happening through Bluestacks. Bluestacks most likely won't make an ARM port (especially cause I doubt Microsoft would allow it in the store) and if we did have access to source code, it's still built around running on Intel processors, and would probably have to go through all sorts of unnatural emulation... So making a totally separate Android program from scratch (which would require inordinate amounts of work) would probably be the best bet.

No. I think bluestacks is actually "just" a port of the dalvik VM to run on windows.
Android apps are not compiled for a specific CPU type. They are compiled for the dalvik virtual machine which is in a way similar to the java virtual machine, in fact a dalvik applications source code is java source code hense why many people say android apps are java, in reality the dalvik VM is very different from the java VM and the 2 are not compatible.
The vast majority of apps do actually work on x86 just fine.
The main problem is that google restricts apps based on your device and often it doesn't recognise x86 devices so doesn't show results, the default app manifest files don't actually restrict platform but many devs set them to arm for some reason. With various tools to spoof what device you appear as you can still gain access to thses other apps.
The problem apps are those that use the NDK (a small minority). NDK apps do have native code, but not just for ARM. The NDK default settings are to generate binaries for ARMv7, but it can be set to x86, ARMv6, MIPS or to compile multiple binaries for a mixture of the above (causes its own issue as it includes the binaries for all platforms in one APK which loads the relevant binary at runtime, good for compatibility as one APK covers all devices but makes the final APK massive). x86 devices of course cannot run ARM compiled apps which does include a few big name apps.
I don't know if bluestacks has left it as pure dalvik VM on x86 or if it does include an ARM emulator for the NDK but it certainly isn't just running an ARM emulator and tyen android atop of it.
I don't experience the ram eating effects you mention either.

SixSixSevenSeven said:
No. I think bluestacks is actually "just" a port of the dalvik VM to run on windows.
Click to expand...
Click to collapse
That's exactly what my understanding was as well, although what I'm about to say somewhat contradicts that.
Interestingly, http://www.bluestacks.com/technology.html says that BlueStacks is "fully configurable" and that it "supports" Windows on ARM as well as x86 Chrome, even though neither of those are actually available today. So, not sure if that page is before or ahead of its time.
"BlueStacks employs a lightweight, optimized, soft hypervisor with deep enhancements to support "embedded virtualization". End consumers can enjoy the full Android environment through BlueStacks, or just install Android app icons directly on the Windows desktop."
What the page basically says is that the core virtualization that BS uses is very easily configurable to different combinations or permutations of OSs; that the technology can just as easily run Windows on Android or Android on Chrome as it can Android on Windows, which is the only current release. It also implies that BS can do BOTH a mere dalvik vm (just install apps to the Desktop) as well as a complete system emulation (full Android experience).
There may be hope for RT yet.

As far as I remember, Bluestacks is using QEMU as there base platform. So it's probably still running ARM code in emulator.
I am looking at if we can port the Dalvik VM over to Windows RT. Anybody want to join the explorations?
So far I can see the Dalvik VM has lots of generated ARM assembly code and have huge dependencies on linux.
Porting would need quite a bit of effort.
Developers from Windroy has done it for the Windows X86 platform. If they can do it for Windows RT, it'll be much easier.

An Android phone with better specs runs less smooth to an iPhone with optimized iOS?

As we've seen, Android's flagship phones are equipped with some of the latest and best hardware; however, I read articles that mention Apple iOS takes full advantage of Apple hardware. The iPhone 6S with their A9 dual core processor including 2gb of RAM is able to compete with a Nexus 6P that has a hexacore Snapdragon processor with 3gb of RAM.
On the 6th iteration of Android (Marshmallow), why is Google unable to optimize their OS for their phone's hardware like Apple does?
Edit: My first post was never answered, so I'll try to get to the point. Does Apple's iOS communicate with the hardware more efficiently, whereas Android takes more steps to communicate with the hardware; therefore being less efficient?

It's not Google's hardware. Google does not make the Nexus line.

MrKhozam said:
It's not Google's hardware. Google does not make the Nexus line.
Click to expand...
Click to collapse
I'm not sure why I wrote that. You are correct, every Nexus phone has been manufactured by different companies. On a side note that might change. I read from a few tech news sources that Google is possibly going to take stricter control of the Nexus line and start manufacturing phones under their brand (same way Apple does).
My first post was never answered, so I'll try to get to the point. Does Apple's iOS communicate with the hardware more efficiently, whereas Android takes more steps to communicate with the hardware; therefore being less efficient?

iOS is developed explicitly for Apple's hardware. They know exactly what they have to do to take the full advantage of the hardware. They don't have to optimize the OS for other hardware because it only runs on Apple devices. In fact, Android runs on hundreds and thousands of different devices, which all have different hardware. Android needs to be optimized for the specified hardware but it is not so easy and also Android has to run on very different hardware without loosing compatibility.
The other thing that makes Android slower, is that applications run on a virtual machine. Applications on iOS are native and run directly.
Another point is that Android's responsiveness to the touch screen is worse than iOS' responsiveness. If you tap on something in iOS, it is immediately processed. In Android it takes some little time to process the touch event. Also you can tune up your Android system to increase responsiveness by increasing the allowed events per second on the windows manager and reducing the minimum pointer duration. You can also set the surface flinger velocity higher, so stuff on the screen would build up faster and render faster.
So the conclusion is:
In general, Android's responsiveness is not so good as iOS' responsiveness.
And iOS is made specially for Apple devices, so 100% hardware support is available.
Android needs to run on many many devices, so it is difficult to maintain 100% hardware support and compatibility as well as efficiency.
Hope that is clearly enough

"Specs" are also misleading. If specs on paper told the whole tale, AMD processors would be better than Intel, Mediatek would be better than Samsung and Qualcomm, and the Tegra K1 dual core used by the Nexus 9 would be laughably underpowered. iOS also doesn't need as much RAM as Android (remember, it's Linux based) for the way it handles memory. Don't go assuming that the "slow" speeds and fewer cores you see on Apple devices means that the hardware is inferior. If it were, they wouldn't get such impressive benchmarking scores.

xdvs23 said:
Another point is that Android's responsiveness to the touch screen is worse than iOS' responsiveness.
Click to expand...
Click to collapse
Is this because there's more 'layers' in Android's OS, so it takes more steps for it to create the response?
Thanks for taking the time to write out that long response. It was very well written and explained a lot for me.

This is the same reason game consoles stay relevant years after they come out with inferior hardware. Interesting how it works - better hardware but software can't take advantage cause of the potential audience

techmatlock said:
Is this because there's more 'layers' in Android's OS, so it takes more steps for it to create the response?
Thanks for taking the time to write out that long response. It was very well written and explained a lot for me.
Click to expand...
Click to collapse
It is because of the way android is made. Android was initially made for non-touchscreen devices with hardware keyboard. Later Google added the touch feature over the existing functionality instead of changing the whole system to optimize for touch devices.
---------- Post added at 10:43 AM ---------- Previous post was at 09:48 AM ----------
Planterz said:
"Specs" are also misleading. If specs on paper told the whole tale, AMD processors would be better than Intel, Mediatek would be better than Samsung and Qualcomm, and the Tegra K1 dual core used by the Nexus 9 would be laughably underpowered. iOS also doesn't need as much RAM as Android (remember, it's Linux based) for the way it handles memory. Don't go assuming that the "slow" speeds and fewer cores you see on Apple devices means that the hardware is inferior. If it were, they wouldn't get such impressive benchmarking scores.
Click to expand...
Click to collapse
Do you mean that android is linux based or iOS? Keep in mind that Android uses a modified linux kernel, which is optimized to be used with the Dalvik VM (or ART).
iOS is not based on linux. According to Wikipedia, iOS is based on Apple OS X, which uses the Darwin kernel, which is based on NeXTStep, and the top root of that is unix (BSD).
---------- Post added at 10:52 AM ---------- Previous post was at 10:43 AM ----------
Btw, Android has a delay when handling touch input events. When you tap on the touch screen, the kernel intercepts the touch event, notifies the system about it (window manager), then it is redirected to the currently active window and then it is handled by the corresponding application. The window manager is set to handle 30-60 (depends on the ROM) events per second by default, but I have adjusted it to 1200 and you really notice a difference. By setting the pointer duration to the minimum, the responsiveness is also increased. In that way, the delay is kept as small as possible, nearly coming to iOS level.
AFAIK iOS handles the input event directly. When you tap, the kernel redirects the event directly to the corresponding application which handles the input immediately. Also the performance in native iOS apps (they are written in Objective-C or Swift) is better than in android (written in Java, optionally expanded by C/C++ shared libraries).
Another important factor is that Android applications do all the stuff in the main UI thread by default. That means, whenever you tap on the screen, everything is handled in the UI thread, what causes that the UI is freezed for the time the application is processing the touch event. (Although this is a very very small hardly noticable timespan, it results in lag). Poorly developed android applications are very laggy because they don't use separate threads to do time intensive work.
In iOS instead, everything is handled in a separate thread by default. That means that when you tap somewhere, the UI would not freeze or lag during operations in the second thread. The result is, that you don't experience any lags while navigating through an user interface.
Conclusion is: Android is fast but it does not handle touch events so fast. Also, by default, operations are done in the main thread. On iOS they are handled separate.

What actually is a kernel?

I see a lot of people talking about flashing kernels and stuff, but what actually is it? What does it do? What benefits does it bring to your device?

In the world of Android term kernel refers to a modified Linux kernel. The kernel represents the lowest layer of the operating system in that it is responsible for controlling the hardware. Processor clock, memory accesses and other accesses to the hardware are executed by the kernel,
In other words the kernel generally serves as an interface between the hardware and the rest of the operating system with the program control, the Android runtime ("ART" or formerly "Dalvik"). Since the kernel is, among other things, responsible for the timing of hardware accesses, you can achieve significant improvements in terms of performance and battery life by changing the kernel.

xXx yYy said:
In the world of Android term kernel refers to a modified Linux kernel. The kernel represents the lowest layer of the operating system in that it is responsible for controlling the hardware. Processor clock, memory accesses and other accesses to the hardware are executed by the kernel,
In other words the kernel generally serves as an interface between the hardware and the rest of the operating system with the program control, the Android runtime ("ART" or formerly "Dalvik"). Since the kernel is, among other things, responsible for the timing of hardware accesses, you can achieve significant improvements in terms of performance and battery life by changing the kernel.
Click to expand...
Click to collapse
Thank you so much

I assume you aren't talking about this
The Linux kernel, which Android runs on, is essentially the "core" of the operating system. It interfaces with the device hardware and provides a software platform for applications to run on.
Here's something that should help put things in perspective:
"Devices" in this context means camera, display, digitizer (touchscreen), I/O's such as WiFi and Bluetooth, etc.