I'm not sure that I fully understand your question. Lemme try to answer, hoping I don't end up too far off the mark. Be warned that I'm really not an expect in anything bluetooth-related.
-I believe that the impact of adding A2DP support when porting Android to a device is small, possibly negligible, as long as the underlying hardware can support it. -As far as I know the hardware for the HTC dream (i.e. the device that is sold as the G1 and ADP1) is capable of supporting A2DP. That's all I can say on that subject with a reasonable level of confidence. JBQ On Tue, Jan 27, 2009 at 10:23 AM, JDPig in Norcal <[email protected]> wrote: > > JBQ, > > First of all, your participation here is invaluable to all of us, and > you should know that we greatly appreciate the updates you provide. On > that note... I know that in the cupcake branch there is support for > A2DP (stereo BT)... As this is an Android dev branch and not > necessarily for the device itself, the question remains whether we > will be able to port A2DP support to the device? > > On Jan 26, 6:04 am, Jean-Baptiste Queru <[email protected]> wrote: >> The underlying assumption with my remark is that the limiting factor >> in the progress of any software project (open-source or not) is the >> speed at which the ideas can be implemented by software engineers, not >> the speed at which those ideas can be thought of. In every single >> software project that I've worked on in my professional life, ideas >> were always piling up faster than they could be implemented. >> >> There are two reasons why Google is still working primarily from an >> internal bug database: >> >> -the bug database that we're using internally is more feature-rich >> than what is currently available to us externally, and we depend on >> some of those features as part of our development process. We're >> working on it. >> >> -the internal bug data is not in a state where it can simply be >> replicated on the outside, and cleaning that up is a massive task. >> >> We try not to reject user feedback without a good reason for it. We >> accept feature requests through the external issue database, and we >> follow the activity in that database as our resources allow. We only >> have a fixed amount of engineering resources available to work on >> Android, and that forces us to heavily prioritize what we decide to >> work on. >> >> JBQ >> >> >> >> On Sun, Jan 25, 2009 at 6:10 PM, Sam Hiatt <[email protected]> wrote: >> >> > Thanks, JBQ, for your reply. >> >> > A few comments... >> >> >> Users can vote on issues by starring them (check the mouseover for the >> >> star). >> >> > Cool, I wasn't aware that I could vote on the issue by starring it. >> > Thanks for the tip. >> >> >> Ultimately, though, it all boils down to contributing actual >> >> implementations. Having ideas is one thing, but the end goal is to >> >> actually implement them so that they end up in consumers' phones. >> >> > I think you're missing my point. I don't have the experience >> > necessary to implement all of my suggestions myself, nor do I think I >> > should have to in order to participate in the development process. I >> > would really like to see a place where I could lay out my ideas and >> > get feedback from the whole community to see: 1 - if it's a good idea >> > that would benefit other users as well, 2 - if the idea is feasible or >> > in line with the direction of the whole project, and 3 - if someone is >> > already working on something similar. Maybe then I would gather the >> > motivation to implement the idea myself. >> >> > Locale's feedback forum is a perfect example of what I am talking >> > about. Note how the total # of votes is visible to all users, and >> > Locale keeps the issues updated with notes regarding the feasibility >> > of the suggestions. Also note how Locale never responds by saying "go >> > implement it yourself". >> >> >http://feedback.androidlocale.com/ >> >> >> Google's internal database already tracks more than 1000 unimplemented >> >> feature requests, some of which came from community contributors. You >> >> can be sure that it'll be a very long time already until Google's >> >> Android engineers run out of ideas about what could be added to >> >> Android. >> >> > That's good to hear, but could you please help me understand why this >> > database is kept internal? It seems contrary to the whole concept of >> > open source. Why the lack of transparency? >> >> >> As time goes and Android shifts into a truly open-source project, the >> >> entire community will gain more visibility into the entire process. >> >> We're working hard to get there as quickly as we can, but it's a huge >> >> shift that can't quite happen overnight and will probably keep going >> >> for at least a few more months. >> >> > Also good to hear that you recognize that Android is not yet a "truly >> > open-source project". I suppose that sort of answers my previous >> > question. But really, in the meantime Google shouldn't drive away >> > valuable user feedback by telling them to go fix it themselves. >> >> > Sam >> >> -- >> Jean-Baptiste M. "JBQ" Queru >> Android Engineer, Google. > > > -- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
