Related
This is a must-read.
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
I gather a couple of interesting things from this: 1) the ICS OTA will be a drastic improvement over the ICS ROMs we have now, and 2) I thought it interesting how Google will actually improve UI smoothness in the Nexus S by turning OFF hardware acceleration in some areas.
This really clears up a lot of misconceptions and wrong information people around here seem to pass around regarding UI speed and hardware acceleration
Sent from my Galaxy Nexus using XDA App
Good find man, lot of useful info.
From Degobah
Utterly fantastic find, and a must-read for anyone concerned with Android UI performance. It's quite ironic that due to that 8-MB per-process memory hit, it's actually faster for the Nexus S to render parts of the UI in software. I wonder if the same driver limitations are present in iOS, since they use PowerVR GPUs as well.
For reference, I am including Dianne's complete post below.
Dianne Hackborn said:
How about some Android graphics true facts?
I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:
• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.
• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.
• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.
• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.
• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)
• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.
• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)
• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.
• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
Click to expand...
Click to collapse
Skimmed through it but it seems that its a compromise to free RAM but not really to speed up performance. Maybe faster app switching but not scrolling, animations, etc. Hopefully the Galaxy Nexus comes to Sprint.
Sent from my Nexus S using XDA App
Award Tour said:
Skimmed through it but it seems that its a compromise to free RAM but not really to speed up performance. Maybe faster app switching but not scrolling, animations, etc. Hopefully the Galaxy Nexus comes to Sprint.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
1) Faster app-switching IS improved performance.
2) Maybe you skimmed past this part?
"A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps."
Click to expand...
Click to collapse
matt2053 said:
1) Faster app-switching IS improved performance.
2) Maybe you skimmed past this part?
Click to expand...
Click to collapse
Freeing RAM to allow more background processes and faster app switching would mean (app launching) performance that is no better than what we already have. With ICS and the anticipation of HW acceleration, we all wanted BETTER INTERACTIVE performance. From playing around with it on the AOSP build, I can clearly see its faster than 2.3 on that regard. I experience constant app relaunching, much more than 2.3 so maybe that's what Google is talking about. But Google scaling GPU acceleration back because of RAM limitations is kind of disappointing to me but understandable.
Sent from my Nexus S using XDA App
thnx for posting this again. I have read his post a while ago. And it was very informative. I am beginning to understand Android more. And I'm beginning to get more excited with the upcoming ICS update for our phone.
Award Tour said:
Freeing RAM to allow more background processes and faster app switching would mean performance that is no better than what we already have. With ICS and the anticipation of HW acceleration, we all wanted BETTER INTERACTIVE performance. From playing around with it on the AOSP build, I can clearly see its faster than 2.3 on that regard. I experience constant app relaunching, much more than 2.3 so maybe that's what Google is talking about. But Google scaling that back because of RAM limitations is kind of disappointing to me but understandable.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
Yeah, I think the constant app re-launching is exactly what they are trying to fix by limiting the HW acceleration.
There are also several comments from other members of the Android team about how they are regularly blown away by how well the Nexus S Hummingbird processor handles SW rendering, and that it does so with such ease that you won't notice the difference, because it will be a steady 60 fps, and 60 fps is 60 fps to the user.
But the main thing that I think is important to take away from reading the post is that Google seems to know exactly wtf they're doing in this area, and they're doing a lot of work perfecting ICS performance on the Nexus S before they release it. So anyone who has felt disappointment regarding performance of ICS on the Nexus S so far can be assured that their apprehensions are indeed premature, and the Google team is keenly aware of the exact same performance issues that have been noted in this forum.
Plus they want it perfect on Nexus S because that seems to be the phone most Googlers personally own and use
Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
Click to expand...
Click to collapse
good enough explanation for me. So we can expect a better performing ICS for our nexus S. I am always pissed on how my nexus running on an alpha ICS rom can have a very very slow and painful app switching.
matt2053 said:
Yeah, I think the constant app re-launching is exactly what they are trying to fix by limiting the HW acceleration.
There are also several comments from other members of the Android team about how they are regularly blown away by how well the Nexus S Hummingbird processor handles SW rendering, and that it does so with such ease that you won't notice the difference, because it will be a steady 60 fps, and 60 fps is 60 fps to the user.
But the main thing that I think is important to take away from reading the post is that Google seems to know exactly wtf they're doing in this area, and they're doing a lot of work perfecting ICS performance on the Nexus S before they release it. So anyone who has felt disappointment regarding performance of ICS on the Nexus S so far can be assured that their apprehensions are indeed premature, and the Google team is keenly aware of the exact same performance issues that have been noted in this forum.
Plus they want it perfect on Nexus S because that seems to be the phone most Googlers personally own and use
Click to expand...
Click to collapse
I don't know about you but third party apps with hardware acceleration on is visibly more smooth than the same app on 2.3. Night and day difference. I wonder how much of it they're scaling back. Its too bad that you can't easily upgrade RAM on a phone.
Sent from my Nexus S using XDA App
Award Tour said:
I don't know about you but third party apps with hardware acceleration on is visibly more smooth than the same app on 2.3. Night and day difference. I wonder how much of it they're scaling back. Its too bad that you can't easily upgrade RAM on a phone.
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
I didn't get from her post that hardware rendering within app windows would be disabled. Just that certain parts of the UI will be drawn with software executed by the CPU.
Sent from my Galaxy Nexus using XDA App
Good read! Thanks for posting
Not bad
Thx
matt2053 said:
This is a must-read.
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
I gather a couple of interesting things from this: 1) the ICS OTA will be a drastic improvement over the ICS ROMs we have now, and 2) I thought it interesting how Google will actually improve UI smoothness in the Nexus S by turning OFF hardware acceleration in some areas.
This really clears up a lot of misconceptions and wrong information people around here seem to pass around regarding UI speed and hardware acceleration
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Thanks for the info
Sent from my Nexus S 4G using xda premium
My comments, since I do some graphics work professionally:
Either I'm reading this wrong or Android has an extremely stupid rendering design. I do professional embedded GL graphics (and some Qt) so I'm not up to date with the Android framework yet:
* Why isn't drawing a client-server model where all draw commands are funneled to a unified multi-threaded draw server? That way, each app doesn't need a 8MB chunk of driver memory (which is stupid in itself already especially on embedded, Windows Mobile, Qt on Windows Mobile, etc). Only full-screen apps should have direct rendering to the framebuffer. Android is already suffering from draw consistency, resource contention by allowing each app to direct render. C-S would separate touch event contention from drawing contention that each Android app suffers from and why iOS has smoother UI.
* Why isn't Android using a multi-process scene-graph (each app is a item, and then each item has multiple sub-graphs per app) so Android can not only retain what needs to be drawn per global animation updates, but can instantly and easily cull unnecessary updates per app. Putting each app into an overlay isn't the best way to go without this culling.
* Why isn't Android using "dirty-regions" as another way to cull necessary updates (I assume this is what tiles are)? It should be since its a standard technique that dates back to QuickDraw and QuickDraw II, besides MS's windows API.
* With the pixel-overdraw bandwidth issue, Android can easily first cull through the scene-graph, then the per-app dirty-regions (or stencil buffer*), and then use the hardware-accelerated *depthbuffer to eliminate more overdraw, and draw front-to-back. This is just simplified because there's more modern GL tricks for culling. So, Android shouldn't have to touch each displayed pixel more than once.
* Is Android using pixelshaders at all to accelerate standard widgets such as buttons, etc? There's no reason to have large simplified buttons that can't be replicated by instanced models with pixel-shaders in a scene-graph.
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
.
lol in other words no iOS smoothness for us fail I hope ICS hooks up my nexus s tho
NuShrike said:
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
Click to expand...
Click to collapse
Aye, I agree with you there!!!!!
NuShrike said:
My comments, since I do some graphics work professionally:
Either I'm reading this wrong or Android has an extremely stupid rendering design. I do professional embedded GL graphics (and some Qt) so I'm not up to date with the Android framework yet:
* Why isn't drawing a client-server model where all draw commands are funneled to a unified multi-threaded draw server? That way, each app doesn't need a 8MB chunk of driver memory (which is stupid in itself already especially on embedded, Windows Mobile, Qt on Windows Mobile, etc). Only full-screen apps should have direct rendering to the framebuffer. Android is already suffering from draw consistency, resource contention by allowing each app to direct render. C-S would separate touch event contention from drawing contention that each Android app suffers from and why iOS has smoother UI.
* Why isn't Android using a multi-process scene-graph (each app is a item, and then each item has multiple sub-graphs per app) so Android can not only retain what needs to be drawn per global animation updates, but can instantly and easily cull unnecessary updates per app. Putting each app into an overlay isn't the best way to go without this culling.
* Why isn't Android using "dirty-regions" as another way to cull necessary updates (I assume this is what tiles are)? It should be since its a standard technique that dates back to QuickDraw and QuickDraw II, besides MS's windows API.
* With the pixel-overdraw bandwidth issue, Android can easily first cull through the scene-graph, then the per-app dirty-regions (or stencil buffer*), and then use the hardware-accelerated *depthbuffer to eliminate more overdraw, and draw front-to-back. This is just simplified because there's more modern GL tricks for culling. So, Android shouldn't have to touch each displayed pixel more than once.
* Is Android using pixelshaders at all to accelerate standard widgets such as buttons, etc? There's no reason to have large simplified buttons that can't be replicated by instanced models with pixel-shaders in a scene-graph.
Maybe Android should switch to the Unreal Engine for drawing instead, or some other modern game engine. These are all solved issues. Android has hardware that's generations more performant than the old game systems, but a software engine that's generations behind.
Click to expand...
Click to collapse
In case anyone wonders, this was Romain Guy's reply to the questions above:
"We use dirty regions and overdraw would not be eliminated through the use of a depth buffer since pretty much everything drawn by apps requires blending. We user fragment shaders and instanced models already. Apps don't have access to the framebuffer, they draw inside what we call a "surface" which is basically an OpenGL texture used by a separate process (the window compositor.) Android 3.0 already moves towards a full scene graph approach by keeping a tree of display lists (one per View) inside each window."
Click to expand...
Click to collapse
barmanham said:
lol in other words no iOS smoothness for us fail I hope ICS hooks up my nexus s tho
Click to expand...
Click to collapse
I don't even consider iOS that smooth. Multitasking and app switching in that OS is a big pain. My IP4 and iPod touch 4th slows down a lot when multitasking. To a point that it freezes for seconds.
Sent from my Nexus S using XDA App
I posted with my girls pre 2 and the multitasking in that is perfect
Sent from Oxygen 2.3.2 powered Nexus S 4G
Just a blog re: ICS enabling full hardware acceleration of the GUI. We've all figured it would make our tablets sprint but this is putting things in a new light so I figured I'd post it here.
Linky
I'm sure the programmers and people on top of Android out there knew this. It sort of worries me though. Keeping in mind, Apple is running a totally different system - it sort of makes me respect iOS more so, to know that such a smooth system exists within the limits of 256MB of Memory when we're going upwards of 512MB and still having 'issues'. Don't jump down my throat, I don't want iOS (or an idevice), I'm just sayin'.
Jesus. I've known for a long time that there is something wrong with the way Android accelerates stuff and the whole UI design paradigm, but that's just boneheaded o_o That begs the question though: who made the decision to implement acceleration in such a horrible way and why wasn't it designed properly from the get-go? Anyone who has the slightest experience in OpenGL programming would've been able to tell them they're doing it wrong.
What a stunningly stupid way to implement things.
Just goes to show how much difference it really makes when it comes to having experience in OS development...
I like Android, but this design choice was just... dumb.
FloatingFatMan said:
What a stunningly stupid way to implement things.
Just goes to show how much difference it really makes when it comes to having experience in development...
I like Android, but this design choice was just... dumb.
Click to expand...
Click to collapse
Well, there are several shortcomings to Android exactly because of these kinds of brainfarts, like e.g. the permissions system is terribly sketchy and should've received a lot more Q/A. But now that it's released there's little Google can do about it without breaking compatibility as they didn't even plan for it to be extendable.
I do quite like Android, but it's too uneven to really feel professional or trustworthy. I just recently pondered about what I'd want from a future mobile tablet on my Google+ page and while I didn't mention it there, I feel like Win8 would've been in a terrific position for the OS on such a device if they didn't decide to remove traditional desktop from the ARM-version. I know Windows and Microsoft aren't popular here, but they've got a lot more experience with OS-development than Google and are a lot better at power-management design and acceleration of UI and its drivers, plus they've really put some real effort into security lately. Alas, with them scrapping traditional desktop from ARM-version Win8 won't cut it, either.
You guys should read Google's blog post. That article misses one huge point: the trade off. This was far from a bad implementation, it was just a very different one. If you read the article you would know that ios freezes if you hold your finger on screen while loading a large list, Android does not. Android balances the CPU threads for ui display and data processing somewhat equally, while ios grants utter priority to their ui display thread . Basically, if the ui display thread is busy, data processing stops. Android is the winner, it is ios that will now be limited in speed with this configuration until it is optimized for new hardware much like how Android currently works!
autom8r said:
You guys should read Google's blog post. That article misses one huge point: the trade off. This was far from a bad implementation, it was just a very different one. If you read the article you would know that ios freezes if you hold your finger on screen while loading a large list, Android does not. Android balances the CPU threads for ui display and data processing somewhat equally, while ios grants utter priority to their ui display thread . Basically, if the ui display thread is busy, data processing stops. Android is the winner, it is ios that will now be limited in speed with this configuration until it is optimized for new hardware much like how Android currently works!
Click to expand...
Click to collapse
Uh, it is a bad implementation. You can have both a good implementation AND still balance priority of both the rendering queue and application threads, they are not mutually exclusive.
WereCatf said:
Well, there are several shortcomings to Android exactly because of these kinds of brainfarts, like e.g. the permissions system is terribly sketchy and should've received a lot more Q/A. But now that it's released there's little Google can do about it without breaking compatibility as they didn't even plan for it to be extendable.
I do quite like Android, but it's too uneven to really feel professional or trustworthy. I just recently pondered about what I'd want from a future mobile tablet on my Google+ page and while I didn't mention it there, I feel like Win8 would've been in a terrific position for the OS on such a device if they didn't decide to remove traditional desktop from the ARM-version. I know Windows and Microsoft aren't popular here, but they've got a lot more experience with OS-development than Google and are a lot better at power-management design and acceleration of UI and its drivers, plus they've really put some real effort into security lately. Alas, with them scrapping traditional desktop from ARM-version Win8 won't cut it, either.
Click to expand...
Click to collapse
If Microsoft is dumb enough to kill desktop mode on ARM, that really destroys the Win8 tablet market outside of running on Intel chips, which puts them at sub-par graphics. I suppose the only hope then is if AMD steps in and I'm not all that much a fan of AMD, though they have tried to make good efforts in the mobile arena with their A-series chips and having decent GPUs.
I suppose I'll keep an eye on this and see what Microsoft does. Given their lack of intelligent decision making of late (ie. far dumber than their normal stupidity), I don't hold out much hope. Pity, Win8 tablets were looking strong, too.
Gnoop said:
If Microsoft is dumb enough to kill desktop mode on ARM, that really destroys the Win8 tablet market outside of running on Intel chips, which puts them at sub-par graphics. I suppose the only hope then is if AMD steps in and I'm not all that much a fan of AMD, though they have tried to make good efforts in the mobile arena with their A-series chips and having decent GPUs.
I suppose I'll keep an eye on this and see what Microsoft does. Given their lack of intelligent decision making of late (ie. far dumber than their normal stupidity), I don't hold out much hope. Pity, Win8 tablets were looking strong, too.
Click to expand...
Click to collapse
The Metro-interface is aimed for touch-based devices, including tablets. Desktop-mode doesn't work too well on such. The problem is that Win8 tablet could serve as BOTH a mobile device AND a desktop computer if Microsoft played its cards right and thus reserve a very nice spot for itself.
WereCatf said:
The Metro-interface is aimed for touch-based devices, including tablets. Desktop-mode doesn't work too well on such. The problem is that Win8 tablet could serve as BOTH a mobile device AND a desktop computer if Microsoft played its cards right and thus reserve a very nice spot for itself.
Click to expand...
Click to collapse
Indeed. Being able to handle both of those would hook me in pretty easily.
I'm just wondering, with all the top devices now being on ICS or JB, or having updates in the near future, is there a conscious effort from developers to start recoding their apps in native code to keep them fast, bugfree and light? And if not, what would it take, as an online community to try to get them to do so?
Now, I am not a dev so I realise that anything I say here may be inaccurate, but to the best of my knowledge:
Most android apps are currently programmed in HTML5 or Java, both of which are easy to port and run on all android versions with the power to run them, as they have some kind of virtual emulator to run them, but that means they bottle-neck the phone, they run slow, they force close, these scripts are often buggy and unstable and they don't run or look as good/well as they should. This was great in early days when phones were slow anyways so you wouldn't notice the difference, but iOS and Android (and perhaps WP7, Rim and Symbian) apps would all get the same update in a relatively close timeframe and all be almost the same. In the current world of ultraphones such as the S3, iPhone 5 and Lumia 920, regardless of how you feel about their manufactureres or firmwares, are all powerful and fast phones, all capable of running native coded apps on the latest firmware versions and they are kick-ass all round. Now, native coded apps, as far as I'm aware, no longer need to be emulated, there is no program running to handle them, they are being read as if part of the system itself, kind of a synthetic arm attached to a person rather than a robot being operated by remote control (???), and therefore are faster and more efficient and if coded well, stable.
Apps currently seem to be the bottle neck on my s3, I can make the phone speed through the internet like there's no tomorrow, but if I open, for argument's sake, the YouTube app, it takes 2 or 3 seconds to open. The Facebook app (yes, Suckerberg has confirmed a native app for Android similar to the native iOS app for this one) is still kind of slow though I think it isn't as bad as people say. Lots of apps crap-out and die or load much slower than they should when 4 cores are pumping pure mobile testosterone into them, so we really need the boost.
A lot of iOS apps are natively coded now, they load up so fast on the 4S, and they are more reliable, which is a shame, because for obvious reasons I love the S3 much more but I find myself still reaching for the 4S for certain actions because I know that the apps will be ready quicker and wont decide they've had enough and die half way through use.
What do you guys, many of whom know more about this kind of stuff than me, have to offer in terms of this subject or what are your opinions?
This is specifically development related how? Wrong section.
OP, Please read the rules about posting and the proper places to post.
If you need to revisit the rules the link is in my sig. Please do NOT post non development threads in the development section.
Thread moved to general
Sorry, my logic was that 3rd party apps talk was to p do with developers and development, my apologies.
So, any answers?
There is a very simple reason to use Java for apps - write once run anywhere. If apps were native then they would have to be recompiled for every phone. In the Apple world this is not such a big problem but in the Android world this would soon become impractical. Your view on native vs emulated is not correct and probably a relic from Java version 1.0. Native apps do not necessarily run faster than Java apps and in most cases there is not difference in speed. People make a lot of assumptions that because its a virtual machine that it will be slow. The Davlik VM uses highly optimised byte code and is simply not the case. Most Android apps are UI and I/O bound and not CPU bound so you will not see any performance improvements by making them native. You mentioned loading times. Most apps are Odexed to optimise loading so its as fast as possible. Also bear in mind that many CPU intensive tasks are often handed over to specific chips i.e. graphics is handed over to the GPU e.g. a native call to OpenGL will be the same speed as a Java call to OpenGL. Games are the most CPU intensive apps you get on a phone but Android provides hardware acceleration pipelines to handover the workload to the GPU and not the CPU. So for significant majority of applications you will not notice a speed difference between a Java app and a native app and this applies to many other platforms and not just Android phones. This is of course not true for the kernel. Since that has to deal with multiple apps all accessing resources possibly simultaneously then that has to be as fast as it possibly can be. This is why the kernel is native but all of the apps that sit on it are not. Since there are a limited number of kernels usually one per version of Android, each manufacturer has no trouble porting that since that's much easier than porting millions of apps.
Also, your assumptions that non Java code is bug free is also not true. Apps in C/C++ are just as likely to have bugs in as Java code. In some cases they are more likely because you don't have to worry about memory management in Java because of the Garbage Collector in the VM. It sounds like you experienced some poor performing apps but this will be to do with poor coding and not because its written in Java.
So deploying apps in native code would be a major headache when when testing and debugging on multiple hardware platforms and the unlikely speed benefits of native are likely to not be visible to the end user. We would not have the rich world of apps on Android and multiple Android hardware vendors that we do today if apps were native.
I hope this answers your query.
dodgebizkit said:
I'm just wondering, with all the top devices now being on ICS or JB, or having updates in the near future, is there a conscious effort from developers to start recoding their apps in native code to keep them fast, bugfree and light? And if not, what would it take, as an online community to try to get them to do so?
Now, I am not a dev so I realise that anything I say here may be inaccurate, but to the best of my knowledge:
Most android apps are currently programmed in HTML5 or Java, both of which are easy to port and run on all android versions with the power to run them, as they have some kind of virtual emulator to run them, but that means they bottle-neck the phone, they run slow, they force close, these scripts are often buggy and unstable and they don't run or look as good/well as they should. This was great in early days when phones were slow anyways so you wouldn't notice the difference, but iOS and Android (and perhaps WP7, Rim and Symbian) apps would all get the same update in a relatively close timeframe and all be almost the same. In the current world of ultraphones such as the S3, iPhone 5 and Lumia 920, regardless of how you feel about their manufactureres or firmwares, are all powerful and fast phones, all capable of running native coded apps on the latest firmware versions and they are kick-ass all round. Now, native coded apps, as far as I'm aware, no longer need to be emulated, there is no program running to handle them, they are being read as if part of the system itself, kind of a synthetic arm attached to a person rather than a robot being operated by remote control (???), and therefore are faster and more efficient and if coded well, stable.
Apps currently seem to be the bottle neck on my s3, I can make the phone speed through the internet like there's no tomorrow, but if I open, for argument's sake, the YouTube app, it takes 2 or 3 seconds to open. The Facebook app (yes, Suckerberg has confirmed a native app for Android similar to the native iOS app for this one) is still kind of slow though I think it isn't as bad as people say. Lots of apps crap-out and die or load much slower than they should when 4 cores are pumping pure mobile testosterone into them, so we really need the boost.
A lot of iOS apps are natively coded now, they load up so fast on the 4S, and they are more reliable, which is a shame, because for obvious reasons I love the S3 much more but I find myself still reaching for the 4S for certain actions because I know that the apps will be ready quicker and wont decide they've had enough and die half way through use.
What do you guys, many of whom know more about this kind of stuff than me, have to offer in terms of this subject or what are your opinions?
Click to expand...
Click to collapse
Amazing answer.
Sent from an electronic device.
If your reaching for your 4s you should be on medication....
Sent from my GT-I9300 using xda premium
I don't buy that "native apps need to be compiled many times so it's a major headache" argument. The compilation can be done as a part of the deployment to store process. Play store knows the phone it installs the app on so can substitute a right executable. It can all be done behind the scene. Linux is C++ and yet is deployed on many various platforms.
Google should rather encourage people writing native code for performance critical applications rather than discouraging it, what they are doing now. Things like launchers, maps, browsers should be native. Java is often a lot slower than c++. If you want to see this try comparing map rendering in native and java in OsmAnd for example.
Adittionally, apps performing fast drain proportionally less battery, as they use less cpu cycles to do the same job. This is an important factor on mobile phones.
I've been professionally coding for 13 years both in c++ and java and have a good clue what I talk about. Also java coders tend to be less organized than c++ ones, which can explain the fact that we see more fc's on android than crashes on windows. A friend of mine likes telling "java is a language for programmers who cannot program".
"Smartphone is no longer a phone"
ahacker said:
Also java coders tend to be less organized than c++ ones, which can explain the fact that we see more fc's on android than crashes on windows. A friend of mine likes telling "java is a language for programmers who cannot program".
Click to expand...
Click to collapse
I call troll.
If you'd been a professional developer for 13 years you would know full well that both those statements are utter tosh.
Geoff (professional developer - not java - for 17 years)
Sent from my GT-I9300 using xda app-developers app
ahacker said:
Linux is C++ and yet is deployed on many various platforms.
Click to expand...
Click to collapse
If by "Linux", you mean the kernel then no. Linux is written in C. The GNU coreutils are also C. (Though the GCC people do want to make GCC a C++ program. But I digress.)
Sent from my GT-I9300 using Tapatalk 2
If you do raw speed benchmark tests to CPU intensive apps then a compiled app will always beat a VM app. Benchmarks do vary widely based on the type of benchmark and what compiler optimisations you turn on. This adds a complexity to your idea of letting the Play Store do the compilation. As a developer I'd hate to be in the situation that my compiled app worked fine on my phone and emulator but didn't work when compiled by the play store. How would you debug that? However despite native being faster the speed benefits are almost entirely hidden in most apps because they are interacting with the user, downloading from the web or offloading to the GPU. In my last mail I didn't even touch on security. Using a VM is a very neat way to give an app a limited security sandbox which is very secure.
I think you're maybe being a little harsh on Java programmers. You get good and bad programmers in any language. I think the reality is with a language as open as Java you get more "have a go" programmers which can result in some very dodgy apps on the Play Store. However, the developers of the core Android apps do not fall into this category and its the core apps that we really care about here.
I myself have over 20 years experience coding an Java, C/C++ and a variety of different platforms but rather than descend into a Java vs C++ war and focus back on the original question. The efficiency gains using native are not enough to warrant having to support native apps. If they were, a tech savy firm like Google would have done it. I think the security, support and deployment advantages far outweigh the performance gains for most applications. Sure there would some parts of a few apps that may benefit from the optimisation that native would provide but to facilitate native development Google would have to provide two APIs. Instead Google has ONE platform for all apps, theirs and everyone else's which is very sensible. If Google had to support a native API and a Java API then the doubles the support and development work which would increase time to market and increase cost. For a commercial company the right solution is always a balance between the right technical solution and practicality and cost considerations.
Marsbar said:
I call troll.
Click to expand...
Click to collapse
I call an aggressive idiot, who instead of arguing against my points attacks me personally.
"Smartphone is no longer a phone"
ahacker said:
I call an aggressive idiot, who instead of arguing against my points attacks me personally.
Click to expand...
Click to collapse
If you really think that was a personal attack you have some issues.
To come to a developers forum that is likely to have a high proportion of java developers and say that about them is a troll, pure and simple. If you want to prove otherwise then make an argument that makes any sort of sense.
Quality developers develop quality code whatever language they use. I've worked on quality codebases in VB6 of all things and I've worked on C++ from supposed professionals that made my brain spin from the mess.
Sent from my GT-I9300 using xda app-developers app
Then what is the advantage of native coding?
dodgebizkit said:
Then what is the advantage of native coding?
Click to expand...
Click to collapse
These days, when the majority of app time is io and memory bound and when things like graphic manipulation is handled by the graphics chips or (failing that) by tightly optimized native libraries, far less than you might think, especially since dalvik (the android jvm) comes with a just-in-time compiler that effectively turns java bytecode into native code. Any advantage there might be is rarely worth the extra development time required.
People like Mozilla are perhaps the exception in that they have a huge amount of investment in legacy code that would cost a fortune to redevelop. But for a new app, there's little obvious advantage.
Sent from my GT-I9300 using xda app-developers app
This is just so annoying.
I was playing a game on FPSE during the lunch break. At 13:30, back to work, did not have the opportunity to save my game. Nevermind, I just put the telephone on screen saver / lock screen so that I can continue later, after the work.
...
...
...
Meanwhile I received a text. Fine, I can read it and possibly answer to it... Android is supposed to hadle multitask rather well after all.
...
...
...
Pwned.
After texting, back to FPSE, just to check and make sure that it's still on... Just to notice that the app has been killed by Android...
This is sooo annoying. It's supposed to be mobile phone specialized in gaming. You should be able to interrupt your game to answer a call or a message!!!
I previously owned a Nokia N8 Powered by Symbian^3. It was much much more efficient. Could lauch many apps without worrying of the multitaking. Apps where running in the background, not simply killed by the OS...
Any similar experience to share guys? (or solution, but I doubt there is any...)
What you are experiencing is the brilliant idea of putting a small amount of ram into a android gaming phone (well thought out, Sony). When the ram is low and another app needs to use that ram, Android will automatically kill another app to claim free ram. The problem Android has is it uses Java as the base programming language. The problem with Java is it is a resource hog and totally steals as much ram as possible...see the problem yet? Also, the problem Sony has is that they are stupid.
And now for the reasons. Google choose Java as the base because of its popularity and ease of use for noobs at programming, which is also why there are so many bad apps in the Google Market compared to the iphone. While this was a smart choice for Google at the time to help accelerate their market growth to help catch up with the ios market, it's now a problem they'll always have as a consequence to that choice. To counter this problem of having a horrible base program language android phones constantly needs to have ridiculous specs in order to have comparable performance to the iphone (quad core, gig of ram, phones anyone?).
So there you have it, the core and unavoidable problem with Android. An operating system so inefficient that it warrants quad cores with close to pc specs (That is amazingly bad). So bad that they must've been really high when the folks at Sony thought it was a good idea that a GAMING phone would only need a single core with crap ram. Well played.
So what you are saying is, the entire Android platform is garbage because you made that decision with a garbage phone? Try multitasking on the SG3, then come back. Or, go deal with the fake multitasking of iOS.
you can try supercharger, n use multitasking choice, that's the best multitasking option that i ever try, altough it will makes your free RAM under 70 MB, but multitasking is very great....
DubleJayJ said:
So what you are saying is, the entire Android platform is garbage because you made that decision with a garbage phone? Try multitasking on the SG3, then come back. Or, go deal with the fake multitasking of iOS.
Click to expand...
Click to collapse
All I'm saying is Android is inefficient. This is generally known and Google has been constantly criticized because of it. Going back to my point, this is why manufactures are pushing out quads on their phones.
@cityhunter62
@coreyon
So, why are you even here?
narflynn619 said:
@cityhunter62
@coreyon
So, why are you even here?
Click to expand...
Click to collapse
I provided information on the problem...? I think a better question would be why are YOU here? You didn't provide anything on this thread.
just wonder if V6 supercharger bulletproof app might help?
Tje great thing about android is that normally there is an app for whatevet you need or a flashable zip or a script ect so it just takes a quick search and abitta time and you could be tip top and there's allways the quick save feature in fpse
Sent from my R800i using xda app-developers app
narflynn619 said:
@cityhunter62
@coreyon
So, why are you even here?
Click to expand...
Click to collapse
Coreyon answered to my question and I thank him for that. Now I understand why multitasking does not work on Android, or at least on Android phones with few ram. Still, N8 had 256mb ram but handled multitasking perfectly.
Anyway, mathacer and foryou168 gave some advices that might be helpful. I had some answers, that was the point of this thread...
I'm sure I'm not the only one who experienced that kind of problem...
coreyon said:
All I'm saying is Android is inefficient. This is generally known and Google has been constantly criticized because of it. Going back to my point, this is why manufactures are pushing out quads on their phones.
Click to expand...
Click to collapse
Inefficient because it ran out of RAM? OEM's are pushing for quads because the software and Linux foundation is the most advanced out there. No other mobile is has such supreme multitasking and such a myriad of emulation apps.
Enable zRAM or use a swap partition if you expect this low-RAM device to keep a 32-bit-era console emulator in the background while doing phone functions.
Or get a tablet for gaming. Its still just a smartphone dude.
Or get an iPhone.
Or learn development and help the "horrible android" to be better.
Sent from Xperia Play (R800a) with Tapatalk
Just don't say that android is rubbish,.. it's awesome.. And it's open.. we can customize our phone to our need... that's make it different..
Sent from my GT-I9100 using xda premium
Android is insufficient, but on my Galaxy S3 samsungs multitasking is absolutely terrible for 1GB, but now once I flashed the Multitaskingfix I have to say its like multitasking on a 2GB android device, I love it! and in the latest leak (with Multi view, etc) XXELK4 4.1.2 the ram used is almost half of what is used on 4.1.1, Love you samsung! can't say that about Sony, but Xperia play will always be with me until I get use to Touch screen gaming.
For everyone that somehow got offended when I said Android is inefficient, please read on. Android IS inefficient, but that does not mean it's a bad operating system. I personally use it myself. It's certainly better than ios with Apples lockdown. The great positives of Android is that it uses the Linux kernel which is very advanced, and the entire operating system itself is very customizable (partly thanks to java it self).
Now with that said, like I've mentioned I don't know how many times now, it will always have a problem as apps and games become more and more advanced; there will always be the new apps that pushes the hardware to a new level and with the Android overhead will cause it to be slower than it could be. A good example of this is how Minecraft (with its amazingly bad graphics) on the PC needs Crysis-like specs to play with good fps on a PC. That's ridiculous, and it's because the game runs in Java. I know there is Minecraft for Android, but let's be honest it's a very very small map that barely has any of the pc gameplay, otherwise the phone would explode. However, just like Android, even with Minecraft's horrible lag issues it is still an awesome game, and is very easy to customize the game which is also very awesome. Does everyone understand my point now?
CosmicDan said:
Or learn development and help the "horrible android" to be better.
Click to expand...
Click to collapse
I AM a developer, and I have had the pleasure of struggling with Java's limitation on a multiple array of platforms. I do know what I'm talking about, it's a well known issue.
I'm personally suprised Java is still alive
Thought it would have died years ago because java programs would be slow as molasses/bog down any PC.
So I'm surprised it actually runs decently on phones... tho the phones are more powerful than PCs from a few years ago lol
And yeah, its' the same old cycle.
Software always gets bloated as hardware specs increase so it's tough to get ahead - kinda like how inflation negates pay raises
coreyon said:
I AM a developer, and I have had the pleasure of struggling with Java's limitation on a multiple array of platforms. I do know what I'm talking about, it's a well known issue.
Click to expand...
Click to collapse
I can agree from my experience with Java software, especially the security concerns. I heard a saying: hell is a world where Java is the only programming language. I'm more annoyed by Google trying to do things different and separating itself from Linux standard.
I have to say you are very lucky to present your thoughts here, if this was a Nexus forum all hell would break loose. The Nexus fanboys are relentless.
Sent from my Galaxy Nexus
eksasol said:
I can agree from my experience with Java software, especially the security concerns. I heard a saying: hell is a world where Java is the only programming language. I'm more annoyed by Google trying to do things different and separating itself from Linux standard.
I have to say you are very lucky to present your thoughts here, if this was a Nexus forum all hell would break loose. The Nexus fanboys are relentless.
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
Aha, I should've made a thread for this. This went way off topic from the original purpose of the thread.
JAVA OS?
I thought IOS apps were Java also?
Either way, they have similar "multitasking", except that the programmer can control how an Android app "moves through the states" (ie. from pause when its in background to being killed) so if the FPSE programmers took advantage of the power of Android OS, they could have set the game to do a save as it was killed...
In fact, Android AUTOMATICALLY dumps some of the programs memory when killed involuntarily (the OS needs more RAM) so really, all the programmer needs to do is check to see if there is a bundle already there when the programs oncreate() is (re)called - if so, then resume!
developer[dot]android[dot]com/training/basics/activity-lifecycle/recreating.html
For the record I hate Java, and more so - ECLIPSE (Java IDE that was also itself made in Java) makes me want to shoot myself in the face whilst listening to Enya and letting spiders crawl on my testicles.
Hicsy said:
I thought IOS apps were Java also?
Either way, they have similar "multitasking", except that the programmer can control how an Android app "moves through the states" (ie. from pause when its in background to being killed) so if the FPSE programmers took advantage of the power of Android OS, they could have set the game to do a save as it was killed...
In fact, Android AUTOMATICALLY dumps some of the programs memory when killed involuntarily (the OS needs more RAM) so really, all the programmer needs to do is check to see if there is a bundle already there when the programs oncreate() is (re)called - if so, then resume!
developer[dot]android[dot]com/training/basics/activity-lifecycle/recreating.html
For the record I hate Java, and more so - ECLIPSE (Java IDE that was also itself made in Java) makes me want to shoot myself in the face whilst listening to Enya and letting spiders crawl on my testicles.
Click to expand...
Click to collapse
I don't touch ios even with a 50 foot pole, but I'm pretty sure ios apps don't use Java. Even if they did, the core operating system doesn't, and that's enough to make a huge impact difference in performance.
I heard about some developer porting Android to C+. By passing all those legal issues with Microsoft, if Android ran on C+ wouldn't it fix all the lag much like Project Butter has and evidently fixed the incredible RAM usage by the device?
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
mikeserv said:
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Entropy512 said:
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Click to expand...
Click to collapse
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
mikeserv said:
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Entropy512 said:
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Click to expand...
Click to collapse
Wow. Strong words. You consider PulseAudio an existential bane, huh? Can I ask what sound daemon you use instead? I suppose it's possible you do without. Though it seems OSS is entirely deprecated, ALSA can still provide minimal functionality without a user-space management daemon if necessary, but without some extensive and, at least to me, seemingly esoteric initial configurations, good luck handling even a lasting volume adjustment without root access (or be in the "sound' group, I suppose), and should you have occasion to simultaneously offer two applications sound privileges... Sorry, grinding my teeth again.
Anyway, I didn't much like PA at first either, but I wanna say my first encounter with it was Ubuntu 7.10 or so, or thereabouts. I've since adopted the greener pastures offerred by several other distributions, less brown anyway, but PulseAudio is a fairly static component of my sound system as configured by default by distro maintainers no matter where I wander. Even on systems I build up myself from very little, when PulseAudio is included it tends to be one the things I have to consider least as trouble goes. The plugin support is very extensive these days as well.
When PulseAudio is combined with Bluez for instance, it can emulate almost all of the headset profiles, to include a telecommunications headset, and can easily record from this stream or any other because every one of PA's sources can be easily multiplexed. It's fun, and very powerful. PA can do on cheap or even no dedicated hardware at all what Airplay only aspires to. And these days, it even makes it easy. It's a true sound server, and while it can be utilized simply enough with Android satellite clients if you set it to emulate Airplay, to serve a multi/unicast, and/or to emulate the DLNA protocol, even this impressive scope of functionality is much diminished when compared to two PA servers working in concert.
Other desktop alternatives do exist, of course. There's Jack, designed to provide low-latency, realtime audio rendering, but these days it seems it too seems to operate best, and is most often configured to do so by default, in conjunction with a PA daemon. And MPD of course, which I confess I have much interest in, but very little other incentive otherwise to actually try for myself. I don't actually known what it's capable of. Perhaps you do? I wonder, is it just, as is eponymously implied, a music player daemon? Or can it actually be extended to do the kinds of things I've come to expect of PA as hinted at above? I really should find out.
Anyway, if you haven't had a look at this, it might interest you: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
The author takes care to provide many impressive benchmarking results as proof of the worth of his efforts. If that sparks your interest, you'll find the Android port homepage here: http://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Android/.
And try to remember that PulseAudio is a more mature and proven project than is Android itself, much less SoundFlinger, and each of these three could be said to have experienced some rather rocky starts.
As for the Bluez project being recently dropped from Android and its even more recent Android-focused development, I believe these things are likely just as related as they appear to be. I would have to dig deeper than scanning a few kernel changelogs to be sure, but as I understand it for about a year or two, Bluez has been undergoing a codebase overhaul. I expect that in such a scenario the Linux kernel's default Bluetooth stack would have to focus initial efforts on the Linux kernel's core x86 support, and especially providing ARM support would prove difficult due to its lack of a default firmware interface and handling the myriad hardware access mechanisms might just have been too much at the time. Again, these are my assumptions, but what has definitely happened recently is a concerted effort at full Android support. If my assumptions are correct, then probably the Bluez project just got caught up is all. In any case, the functionality Bluez provides, especially where networking transparency is concerned, is definitely superior. Find out for yourself if you'd like to know.
Surely I'll find out for myself soon, as I guess i'll be diving in after all. Never built Android from source before, which doesn't make much sense as I've had nothing but Android devices since my G1, every one of which, up to and including the Dream, was rooted and flashed with at least a replacement recovery pretty much on day one. I guess better late than never, though.
Back soon, I expect! Best wishes!
-Mike
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
*edit of this mistakenly resulted in double-post below*
Entropy512 said:
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
Click to expand...
Click to collapse
Maybe that's true, but if you asked me I'd probably lean the other way and say instead that Ubuntu is in too many places. Honestly, PA is really not complicated if you consider it a suite of core sound apps as opposed to a single, cohesive application. Probably my biggest gripe with Ubuntu's interfaces is that they often do the opposite, which is of course contrary to Unix principles, and in the process they tend to sort of opaque over simple and accessible modular designs.
I won't attempt to argue that PulseAudio is simple by design, as we both know I'd be certain to lose that argument, but it does offer a few lesser known interfaces you might find interesting. For instance, one of my favorite little tools is pacat. This does exactly what it sounds like; point it at one or more of PA's sources and it will concatenate their raw audio output into stdout at which point you are free to pipeline it as you would any other stream. Imagine you took pacat, perhaps also lz4, nc, and another little pipe-friendly PA tool called paplay directed at a PA sync on its system rather than a source, and combined them all into a pipeline. I hope in this you might begin to see some of PA's merits that perhaps you've missed before.
Also, there is pacmd, which is not nearly as straightforward as those others I've mentioned, but is far more capable and very well documented. It can do anything PA can do, really, and is fully scriptable.
I don't know which versions of Ubuntu you use, but those not on rolling releases may not yet have caught up to the PA update that implemented a PulseAudio-module-specific udev adaptation. Newer PA versions now pretty much auto-configure audio modules in the same way early user-space handles kernel-module loading. It's kinda cool, and almost an entirely hands-off process.
Anyway, I'm through proselytizing. I just thought I'd mention these things because they're the bits that I use when I want to do something with it.
EDIT:
Entropy512 said:
...because of my experiences with it, I will never personally put any effort into putting it into more places...
Click to expand...
Click to collapse
I looked again and noticed this. While I fully understand where you're coming from here, I thought I heard some French kid on YouTube say that this was not the sort of response that should be expected for OmniRom feature requests. He described a sort of democratically driven road map, and specifically he said that if a feature request was well enough supported by the users, then the developers would implement it even if they did not agree it should be done. Has this policy changed?
Of course I realize that youtube guy was probably talking about majority rule as opposed to a well-argued request, and that I'm only one person, but above you say you will never do this thing, without making any allowances for the possibility of a vote or poll or similar.
Like I say, I fully understand your position on this, as I, of course, do not intend to devote my own efforts to something like further Android fragmentation for instance, vote or no vote. I just wish to know what to expect here, and if maybe I missed something.
-Mike
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients - All apps would have to be presented with something that is "audioflinger-like" which didn't offer the extra features offered to clients. Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Entropy512 said:
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Click to expand...
Click to collapse
Wow, man! Thanks very much indeed for replying with honesty and humility. I'm very pleased that I didn't, or at least I hope I did not. Even if you had said otherwise I would have fully understood, of course, but as it is, I'm also very impressed. I like discussion. Thanks, man.
Two questions: what's yamahell? And, because you say you've worked with it, can you tell me about AudioFlinger or whatever it is and maybe why the status quo is desirable? I thought it was a problem. I'm asking these things for my own edification and because I think I'm gonna try something to do with a PA replacement.
While I agree PA may be overkill, I really don't believe pulse has to be applied monolithically, you know? It's already designed to work with modules, so maybe a subset would be sufficient. Clients only communicate with libpulse.so for the most part, for example. And for the past few months (on an upstream system) PA and Bz have been working really well together. So I'll try it, maybe, after you tell your horror stories and I can judge for myself.
-Mike
-
Entropy512 said:
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients...
Click to expand...
Click to collapse
I assume you mean the first one, the blog on the initial port? Well, I believe that may have changed since then. The actual port homepage at freedesktop.org (the second link I provided) says this:
Code:
...[T]ested on Samsung/Google Galaxy Nexus as ... reference implementation... [P]ort fairly straight-forward for ... devices with ALSA support.
Various bits of functionality are available, and this is a moving target. The following are tested at the time of writing this section:
Audio playback for most apps using native Android APIs
Volume control
Switching of outputs depending on the device plugged in (headphones, headset)
To Be Done
The following pieces are either partially or not at all implemented
Audio playback API completeness: infrequently-used bits of the API (loops, markers, etc.) are not implemented
***BIG ONE*** Calls: this is work-in-progress, but needs to be cleaned and merged
Policy: initial implementations of volumes and port switching are done. There are probably a lot of bits of policy that still need to be implemented for us to have feature/bug-parity with standard Android.
Audio record API: can be implemented fairly easily like the playback API was
***NOT CLEAR ON THIS*** Audio effects API (we don't support this in PulseAudio at the moment)
Entropy512 said:
Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
Click to expand...
Click to collapse
Something tells me this is a statement I should be able to fully comprehend before getting neck deep...
Entropy512 said:
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Click to expand...
Click to collapse
It doesn't look so huge to me, as much is already done, I think. But then I've to hear your horror stories so I will reserve judgement.
Entropy512 said:
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Click to expand...
Click to collapse
Yes, that article was written then, but the freedesktop.org homepage was created March of this year. I suspect some changes have accumulated along the way, and because PA is an actively developed high-profile application hosted and backed by RedHat, I expect that website landing page would be removed soon after it became irrelevant. I will, of course, reach out to the maintainers at that end as well for advice.
But... that's kind of the point... less redundancy, you know? Less fragmentation? No need for separate groups for thisnkind of stuff. I just thought that was inline with omni ideals. Is there another way that you know of that could as easily bring a like convergence of functionality with other Linux systems? I just wanted to effect something along those lines and I thought omni sounded like a place worth starting.
Also, I want those things.
-Mike
P.S. This is the git repo described in the .XML repo definition for the PA build-code at freedesktop.org: http://cgit.collabora.com/git/
You can see the android specific PA packages are being worked on, and very recently. Also, ALSA is seeing somewhat recent dev work as well.
EDIT: This may not even be quite as difficult as i initially assumed.You can also see at the following git repo that a commit was made to master referencing 'mako' 5 weeks ago.
http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/
yamahell - the hell that was working with the Yamaha MC1N2 codec seen on many Galaxy S2 family devices.
Poorly documented, kernel code written by a member of a primitive tribe with no concept of zero, Samsung's blob HALs doing all sorts of unpredictable crap requiring workaorunds and hacks...
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Entropy512 said:
...no concept of zero...
Click to expand...
Click to collapse
....should I?
Entropy512 said:
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Click to expand...
Click to collapse
This makes very good sense. While I think the PA 4.0 changeligs from July or so may acknowledge this lack they also seem to indicate it's been addressed. Would you mind looking? Not positive I'm reading it right.
-Mike