richard hyndman: oh, thisis definitely on. hi there. and welcome to this talk onbluetooth best practices. my name is richard hyndman. i'm on the android team. and i head up android developer relations for europe. scout sinclair brody: i'mscout sinclair brody. i'm a product manager onthe android platform.
matthew xie: hi. my name is matthew xie. i'm the android techlead for bluetooth. richard hyndman: ok, let's getthis show on the road. so thank you all forcoming today. i'm pretty sure that some ofyou out there must have suffered at the hands ofthis technology before. yeah, right. we all have.
so thank you very much forcoming along, being open-minded, and listening towhat we have to say about android on bluetooth today. so, picture the scene. the year is-- who can get the year? first person? sorry? audience: [inaudible]
richard hyndman: no. 1994. it's quite a tricky one. it's a bad year forroman numerals. but the people over at ericssonwere sick and tired of having to reach around to theback of their computers to plug-in their serial cables. they tried turning theircomputers around. but then the power buttonswere on the wrong side.
so like any good '90s innovativecompany, they decided to reinventthe whole system. and they came up with bluetooth,as we know, for wirelessly connecting devices, peer-to-peer over short ranges. bluetooth's named after haroldblatand gormsson, blatand being "blue tooth" in english. he was a danish king that unitedtribes together without the use of serial cables.
so that was kind of handy. it's a good name forthe technology. so you get the h from harold--it's a rune--, and the rune for b. put them together, andyou get this bindrune that's the bluetooth logo. we've had bluetoothon android-- there he is-- since version 1.0. that's my favorite animationall deck.
and we had bluetooth 2.0with the edr stack-- headset profile, handsetprofile, but no real apis. so you can use classic bluetoothto connect music to music players, mice tolaptops, or mice with headphones to anythingyou want. but the point is, these thingsneed to be able to talk to each other. the need to be able todiscover each other. they need to be ableto connect.
and they need to be able totalk a common language. and for that, they're goingto need a bluetooth stack. so what's a bluetooth stack? a bluetooth stack is animplementation of the bluetooth core specification. on the bottom of it, you've gotthe rf transceiver doing the actual wirelesscommunications. above that, you've got thebaseband controlling the transceiver.
above that, you've gotthe protocol stack. lots and lots of protocolsall going into there, so you can talk. lots of different types ofcommunication between any two bluetooth devices. so this is a bluetooth stack. and then on top of that, youhave your bluetooth profiles. bluetooth profiles aredefinitions of-- [microphone feedback]
bluetooth profiles aredefinitions of which parts of the bluetooth stack are requiredfor doing each type of communication. bluetooth profiles generallyaren't tied in to any specific version of the stack. they're just definitions-- which codex you need,which parts of the stack do you need. so when you see versions ofbluetooth, you're looking at
versions of the corespecification. version 1, version 1.1, whichwas 802.15, the bluetooth spec was running about amegabit a second. version 2 went up to aboutthree mega second. the little + edr meansin enhanced data rate is optional. version 3, they claim, wasaround 24 megabits a second. not sure i ever gotthat out of it. with the + hs for plus highspeed is an 802.11 wi-fi link.
which brings us upto version 4. let's just say there have beenmany, many different bluetooth stack implementations. in android, we've had the bluezstack, powering aosp devices, samsung and htcdevices, sony xperias. we've also had the olderbroadcom stack. some of the htc before icecream sandwich devices. we've got a motorola bluetoothstack for all host motorola devices.
and then some others as well. and of course, theseare all compatible. but software has bugs in it. we know that softwarehas bugs in it. so potentially, you have to workaround different issues, just little things hereand there with all the different stacks. and whilst we've had all thesedifferent stacks, the android apis that have been available todevelopers and the android
bluetooth functionalityavailable to consumers has also been changing throughoutthe history of bluetooth. matt's just going to run throughquickly the different apis we've had on bluetooththrough the years. matthew xie: yeah, hi. i'm going to just go overandroid bluetooth versions features apis a littlequickly. so as you know, androidloves desserts. so you could say we havea real sweet bluetooth.
starting at the beginning,we included bluetooth. so android 1.0, we havebluetooth 2.0 with a headset and hands-free profile. so you can make a phone callusing your bluetooth headset [inaudible]. now, cupcake, we have a a2dp. you can stream musicover bluetooth. next is eclair. we have bluetooth 2.1with rfcomm apis.
and we also added object pushand the phonebook profiles. then with froyo, voice dialingover bluetooth. honeycomb, we added apis forprofiles, like a2dp and hands-free. honeycomb also added[inaudible] pan tethering, which is youcan connect your bluetooth keyboard, mouse, game pad, andtyping instead of doing that on your phone. and pan is data tethering soyou can share your internet
using bluetooth. and ics added a health deviceprofile so you can stream your medical data real-timeover bluetooth. and then now, it's jelly bean. over to scout. scout sinclair brody:so as you may know-- whoops, went backfor a second. try it again. whoop, too far.
there we go. ok, so as you mayknow, in 4.2, we introduced a new stack. we moved away from bluezto bluedroid. this was a change that was madepossible by a significant contribution to aospby broadcom. there were, of course, somebumps in the road with this transition, for which wecertainly apologize. but we felt that itwas an important
move on several levels. first, we wanted a stackthat was optimized for embedded systems. second, because of conflictinglicensing models, we actually had to run bluez in its ownprocess, which certainly had performance implications. and finally, we really felt thathaving stack development happen in aosp would allowgreater overall velocity, in terms of adding features andadding stability and
performance enhancementsover time. so that brings us to a topicthat many folks are interested in, which is bluetoothlow energy. [applause] scout sinclair brody: clearly,there's a lot of excitement about this technology. and i'm not sure that all ofyou are familiar with it. so i want to tell you a littlebit about what it is and why it exists.
bluetooth, as it was originallyconceived, was designed to interact, allowdevices with relatively large batteries that charge frequentlyto interact with one another. and as rich mentioned, use casesfor bluetooth classic typically involved streamingaudio or other high bandwidth applications. however, the originalspecification was a little bit heavy for devices that have verysmall batteries or that
you don't want to chargeevery day. so bluetooth low energy wasdesigned to work with devices in exactly this category. such as proximity tags that youcan attach to your keys to help you find them, orpedometers or fitness or medical sensors, orwatches, or game controllers, remote controls. there are a whole host ofpossibilities with this technology.
the goal is to let devices thatrun on small batteries like these to go foryears at a time without being recharged. the technology that wecolloquially refer to as bluetooth low energyis actually-- the official brand name of it,as propagated by the bluetooth sig, is bluetooth smart fordevices that support just ble, and bluetooth smart ready fordevices that support both ble and bluetooth classic.
so you might be wondering whyi'm showing a nexus 4 here. because, up until this point,of course, we have not had support for bluetoothlow energy in the android platform. but today, we are excited toannounce that when android api version 18 is released in acouple of short months, the nexus 4 and all future nexusdevices will support bluetooth low energy with developer-facingapis. scout sinclair brody: so thismeans that your apps and your
peripheral devices can takefull advantage of this exciting technology. so in a couple of minutes, we'regoing to go through a couple of code examples, andyou'll get a preview of the apis for bluetooth low energy. but i want to give you a bit ofterminology first that will help you in understandingwhen we walk through those examples. first off, you should knowthat ble is based on the
specification called gatt, whichis what your apps will actually interface with. gatt communicates using theattribute protocol, which, true to its name, transfers datain the form of attributes and operations on thoseattributes. the most basic type ofattributes are descriptors and characteristics. a descriptor, also true to itsname, is just a descriptive tag for another piece of data.
a characteristic consists ofa value and a zero or more descriptors associatedwith it. the bluetooth sig has adopteda number of standard characteristics for expressingsuch diverse information as the day of the week or a bloodglucose value or a sensor's location on a bicycle. i mean, there are all sortsof crazy things in there. characteristics can then begrouped together to form a service, which a bledevice can then
advertise to other devices. a service spec states not onlythe characteristics that a gatt service makes available,but also which characteristics the gatt clients can read,write, or receive notifications about. note that when two ble-enableddevices are communicating, either one can act as theclient or the server. they can even switch off. it all depends on whichone is actually making
characteristics availableto the other one. moving up in the specification, the next bit here-- sorry, there's the clientand server. the next bit here is gattprofiles, which define how data provided by a service isto be exchanged between the gatt server and its clients. profiles are defined withspecific use cases in mind, but are generally designedto be flexible enough to
accommodate multiple scenarioswithin a particular domain. as of right now, there are about20 different ones for a bunch of different use cases. and as of android api version18, you will be able to implement these profiles in yourapps, or future profiles that are released, or customprofiles that you want to define for your application. back to rich. richard hyndman: thankyou very much.
ok, so we had a quicklook at the bluetooth stack for classic. next, we've got the bluetoothstack for low energy as well. the point being, here, that atthe bottom you've got a low energy rf now. this is optimized. instead of streaming data likethe classic stack, just for bursting out these smallattributes of data and then powering back down again, thisis how bluetooth low energy
stays so low energy. and the protocol stack, insteadof being this enormous array of protocols, isreally focused on the one attribute profile. and on the profiles at thetop, instead of all the different profiles, we'vejust got this gatt profile on the top. so the bluetooth le stack is afraction of the size of the bluetooth classic stack.
and because of the low energyrf, it needs a fraction of the size battery. and you get these devices, ofcourse, that are a fraction of the cost and run fora lot longer. so as this talk's calledbluetooth best practices, we should have a look at some ofbluetooth's best practices. to demo this, we're going torun through an example of connecting a bluetooth heartrate monitor to a nexus 4. this is going to be, right now,the only place where you
can see the bluetooth le apisthat we've created. so here we go. although, to start with, youalways need to check if the device has bluetooth. when i was writing this slide,i was thinking, what devices don't have bluetooth? i almost took the slideback out again. and then i thought, only thedevices inside our ecosystem are cts-tested.
and they're the only ones thatwe can guarantee that have bluetooth on. so maybe there are non-bluetoothdevices. and then there's going to bethings like google tvs that also may not be bluetoothdevices. so it avoids horrific crashes. it's always worth checkingif you have bluetooth on the device. matt's just going to run youthrough the code quickly.
matthew xie: yeah so let's talka little about the code. to check whether there'sbluetooth on your device or not, you check bluetoothadapter. this is existing api. but the only way you'll get itis you're seeing static method with a bluetooth adapter,get default adapter. if you look at this code,we are changing that. we're obsoleting that. now we are doing this withour bluetooth manager.
so you see context, getsystem service, with bluetooth service. and then, from the manager, youget the bluetooth adapter. and now you check, if that'snull, then you don't have bluetooth support inyour platform. richard hyndman: ok, so we'vegot a device with bluetooth. of course, you're next goingto need to check whether bluetooth's turned onor off to avoid the next horrific crash.
matthew xie: yeah, you dothis by we provide api. you do this by checkfrom the adapter. you check whether it'senabled or not. if it's not enabled, you cansend an intent to the [inaudible] app to enable it. we don't have an api to enableit directly, because we want full user awareness. so you cannot sneakbluetooth on without the user's knowledge.
richard hyndman: yeah, so youfire off the intent to get the bluetooth setting screens up. right, so now we're ready toconnect the bluetooth le device to the phone. so we have a new flow forbluetooth low energy. we start with a lowenergy scan. and that's going to put thedevice in scanning mode and look for any devices-- any low-energy devices--
that are currently advertisingtheir presence and available for connections. you find the one that you want,you stop the scanning, and you connect to the device. once you're connected,you discover the services of the device. in the case of a heart ratemonitor, it's going to have the heart rate service. then you can find the
characteristics of the service. this is all about how thegatt profile works. characteristics of a heart rateservice, one's definitely going to be the heartrate, the pulse. another one could be thelocation of the pulse that it's checking on the body. maybe you've got it around yourwrist, or around your chest or something. so you can then find the heartrate and then read it.
you can either just read theattributes for the heart rate or register to get notificationsabout them. and here's the code for that. matthew xie: first, you wantto discover the ble device. we provided a new api to do thatin the bluetooth adapter. this is just for le device. you do start le scan. we have two apis. one is just api witha callback.
the other, you can pass in uuidfilters to filter out only the device you'reinterested in. and this api is callbackbased. we send out results throughcallback, so you have to implement the le scan callbackapi with an le scan. and there are three parameterswe're going to call you. one is a device. that's the one youwant to find out. and rssi, which receivethe signal strength.
and the scans record is theadvertisement data in a byte rate format. ok, now if all you're interestedin is just the advertisement data,then you're done. but if you want to use theservice hosted by the remote ble device, you needto connect to it. you do this by bluetoothdevice connect gatt. with this, you connectto the remote device. this is also on callbackbased.
if you look there, there'sa few callback functions, because the connect call ordiscovery call or character read or write callare asynchronous. so you'll implement thecallback function. and when there's results comingback, we will call the callback functions. take the example, like say, whenyou see like discover a service, we'll call back withonservicediscovered with a write status.
and then you can say getservices to catch the service. so with a service is a listof bluetooth gatt service. so you traverse the services. for each service, you canjust go to look for characteristics, or you canuse uuid to find out the service you are interested. and then, the same way, you gointo each service and get characteristics, which isa list of bluetooth gatt characteristic.
with that you can check uuidsand look for the uuid your user is interested. like in this example, trying tomatch the heart rate uuid and get that. and then, you can alsoset notification. and so we'll notify you if thecharacteristic changes. now back to scout. scout sinclair brody: ok. so there's your sneak peek atthe ble apis for android.
this is an excitingtechnology. and we know that you'relooking forward to working with it. there are a few other thingsthat we think you should bear in mind, though, as you'repreparing to do so. first off, since ble will beintroduced in android api version 18, you'll need adevice running the next version of android beforeyou can take advantage of these apis.
however, once they are released,they will be covered by the compatibility program inthe same way that bluetooth classic apis are, which meansyou can count on them being present in new andupdated devices throughout the ecosystem. next, we want you to know thatthe first version of these apis have support for the blecentral role but not the peripheral role. this means that you won't beable to have two android
devices talking to each otheracross the ble, at least not to begin with. next, and speaking to thenature of the technology itself, please remember thatbluetooth is not a type of magic fairy dust that you cansprinkle on your existing apps and have them become suddenlymore battery efficient. it is a different technologywith very distinctly different use cases. and this is a commonthing that i'll see
in talking to people. they'll say, oh, andnow we've got ble! everything's going to be muchmore battery efficient. i'm going to have muchbetter battery life. well, it doesn't exactlywork that way. the data model for bluetoothlow energy is optimized for small incremental updates. with a max theoreticalthroughput of 200 kilobits per second, streaming audio or videois really not possible.
however, if you're looking tosend data over from a sensor of some sort or if you're superforgetful and want to have ble proximity tags attachedto everything you own, bluetooth low energy isgoing to be a fantastic option and definitely a morepower-efficient way to go than classic bluetooth. richard hyndman: right,of course. whenever you're on a mobile os, battery is always a concern.
when you're running wirelesscommunications on a mobile os, it's even more of a concern. so just a couple of littlebattery tips for classic and le. when you're scanning fordevices, once you've found the device you're looking for, ofcourse, tell the system that you've found it and turnoff the scanning. this also serves anotherpurpose, because there's definitely, with some of thestacks, some conflict when
you're trying to make an rfcommconnection with the device you've just found-- and some people are noddingquite a lot-- and if you're stilldiscovering. so don't have discovery on whileyou try and make the connection, and you'll alsosave a bit of battery. also, never loop onany rf functions. there are wireless devices. one might go out of range.
it might lose its batteryor something. so if you're trying to connectto a device and you fail, then just ask the user or do someintelligent logic about whether they want toreconnect again. don't just sit there loopingon the radio. we've see it one or two times,and then, of course, it just depletes the battery, especiallyif you're in a background service and the userdoesn't know what's going on, trying to reconnect tosomething that existed before.
also, don't reinventthe wheel. android beam is prettyestablished now. if you want to do a bluetoothfile transfer, for example, nfc is a great way for doing thebluetooth handshake at the start, for getting the detailsof the two devices. and with android beam, youjust have to set the beampushuris or thecreatebeamuriscallback. and you can make it so when thetwo devices touch, a large file is sent betweenthe two of them.
android beam will do thenegotiation and send the file over bluetooth for you. there's something todo with the rfcomm apis again, as well. initial apis listen usingrfcomm and create rfcomm sockets secure apis. and that means that they needboth devices to have a screen and i/o to be able to make thesecure connection, because you need to do all thepin entry stuff.
so if you try and make a secureconnection, or if you just try and use these apisand it fails, one of the reasons may be that the targetdevice can't display a pin. if that's the case, go backto be insecure apis at the bottom, create insecure andlisten insecure, and it'll create the connectionmuch more simply. to be honest, most the time,you don't need to use the secure apis. if you've got both devices inyour hand, the chance of a man
in the middle attackis pretty slim. so you're going to save yourselfa lot of bother inside your application if youjust go with the insecure ones, because there'sa lot less reasons why they would fail. one last thing. what would any good bluetoothtalk be without a final little teaser? a think it's a good point.
we've got this wholenew stack in there. we're announcing afew other things. so i'm very happy to say thatalso within api 18, in a few short months, we will be addingsupport for avrcp 1.3. and to the people in theaudience that that means something to, they'll bequite happy about that. [inaudible] will be very happyabout that, because he pings me about it every day. avrcp 1.0 was in an earlierversion of android, and it
meant you could connect yourphone to your car stereo and do the remote control. with 1.3, we also add allthe meta data as well. so you'll see your album art. you'll see your track numbers,track listing, album and titles, that kind ofthing, as well. so of course, there has to bean api for that as well. and it's using an existingapi-- the remote control client api.
so anything that's already usingremote control client-- and google music certainly does,and a lot of apps have remote control clientsalready-- will automaticallywork for you. and your car stereo will get allthe awesome information. if you want to have a lookinside the api, have a look inside the media metadataretriever, and there's a whole load of different tagsinside there that you can set on the api.
things like the album art,things like that. and one final thing, make sureyou always call clear on the metadata [inaudible] first, or you're going to mixyour metadata up with whatever metadata was in there first. and it gets all a bit crazy. ok. back to scout to wrap it up. scout sinclair brody:all right.
so we've had a couple ofexciting announcements, including the inclusion ofbluetooth low energy apis in api version 18, alongwith avrcp 1.3. we have office hours immediatelyfollowing the session, over in the androidsandbox that you're welcome to join. i think we seem to have gonerelatively quickly, so we've got some time for questionsnow as well. but of course, if you want tofind out more about the
bluetooth apis and anythingrelating to android, as always, you should definitelycheck out the developer website. and there's a specific linkright there to the bluetooth information. and let's have you stepup to the mics if you have any questions. scout sinclair brody:thank you. so it's hard to tell.
i think we've got atleast one question. so why don't you go ahead. audience: hi. my name is jimmy [? bocham ?] from [? stickerpoint. ?] i have a question aboutthe new api for bluetooth low energy. the first question is, will itsupport multiple devices connected at the same time?
and the second question, willit support devices calling specific apps? so if the app is not runningin the background, will you support this? so let's take themone at a time. first was-- richard hyndman: willit be able to connect to multiple devices. audience: multiple connectionsat the same time.
matthew xie: yeah. yeah, that's a central. yeah, we can connect tomultiple peripherals. scout sinclair brody: ok, so ifyou're running in central mode, such as you'reon the phone-- matthew xie: yeah, weare able to do that. scout sinclair brody: --itcan connect to multiple peripherals. and then the second?
audience: the second questionwas regarding if an le device can call a specific appthat is not running. matthew xie: yeah, so withthese callback functions. even if it's switched inthe background, we will still call you back. audience: so if the app is notrunning, and the le device-- or the phone is on background. it could be on standby orits on the background. and a specific device thatyou've connected before that
hasn't appeared before comesinto range, will you allow to call a specific app? i think your app, you haveto implement our service. so that, if its activity,if you are tending the background, it's stopped. but if you have a service,then we will call that. richard hyndman: yeah, thescanning on the device isn't going to be scanning for newadvertising devices that are coming past the whole time.
the radio is not on scanningthe whole time. so it won't know that a randomdevice has just come into range, i believe. richard hyndman: so you'd haveto have a service that scans to try to find devicesthat are-- audience: so you need to haveit in the background. richard hyndman: yeah, you wouldstill need to have a service in the background. and that would not be greatfor the battery, maybe.
scout sinclair brody: ok,so let's alternate. so let's go on this side. i'm [inaudible]. i have a question. i noticed you didn't mentionany sort of backwards compatibility. is there any hope of that? and do you think there's anyprospects on backporting it? is that even possible?
richard hyndman: so what we'resaying is that it's going to be api level 18 and above andnot be in the compatibility test suite. scout sinclair brody: andthis is very common. when a new api is introduced,it's for that api version. it doesn't necessarilygo backwards in time. audience: so i've alreadystarted using the motorola, the htc, and the samsungble library sdks. is it going to be--
richard hyndman: that'sdefinitely an option. going forward though, of course,all those devices will also, when they get to api 18,have to support the official framework instead of ble apisso if you do want to support those current sdks thatare out there, that's absolutely fine. as always, with android,it's open. but going forward, yeah, youjust have to support this one set of apis, and it'll makeyour life a lot easier.
audience: to support multipledevices connected at the same time, when the app isin the background, how do i know which-- like, in a proximitycase, there are multiple bluetooth tags. and how can i distinguishwhether a particular-- few tags are of interestto me, that are mine. there could be other tagswhich are not mine. so how do i take care of sucha kind of situation.
scout sinclair brody: underthe assumption that you've been encountered thesetags before? audience: yeah. is there an associationin bluetooth le? richard hyndman: well you canassociate inside your application with theid from the tag. so the first time youget the tag, you can say, this is my keys. inside your app, it saysit's found the tag.
and you could giveit a name inside your app, if you wanted. but each ble device is a uniqueid that you'll be able to reference againwhen you see it. audience: so it's completelyapplication-based? richard hyndman: yeah. audience: so it's not anythingto do with the stack itself? scout sinclair brody: no. audience: or the os?
scout sinclair brody: entirelyup to the application. audience: hi, myname is albert. what le profiles willbe supported when api 18 comes out? scout sinclair brody: soright now we support-- there's gatt. there's support for gatt. and you can implement supportfor gatt profiles in your application.
audience: so you're expectingle profiles like heart rate monitors and [inaudible] gatt to be distributed overthe google play store? richard hyndman: theyall run over gatt. scout sinclair brody: yes,they all run over gatt in audience: and they can bedistributed over the google play store? scout sinclair brody: yeah,it's part of your app. audience: is gatt serverwill be supported?
we support. we also open up api tosupport gatt server. audience: gatt server. how about gatt over basicrate over edr? matthew xie: say it again? richard hyndman: gatton bluetooth-- audience: gatt over basicrate over edr. so in the bluetoothspecification, gatt could run over low energy protocol,and also could run
over basic rate edr? matthew xie: yeah, we alsosupport that, yes. so if it's on the basic rate,the api will still work. yes. scout sinclair brody: can youturn the mic back on? go ahead. no, you should be fine. i was asking the techfolks to turn-- audience: oh, hello?
scout sinclair brody:you're good. audience: i didn'tget the answer. i'm sorry. matthew xie: the answer is,the same api will work in that case, too. like, gatt over basic rate. audience: and you mentionedearlier that the peripheral role is not supported. scout sinclair brody: theperipheral role is not
implemented for api version18 at this point, no. audience: how about theobserver role and the advertiser role? so in the gatt specification,there's four roles-- the central, peripheral, observer,and the advertiser. will the other two rolesbe supported, as well? matthew xie: you're talkingabout the broadcaster? audience: the broadcaster. observer.
matthew xie: no broadcaster. observer, yes. audience: no broadcaster. matthew xie: at this point. richard hyndman: we're stillmaking these apis. matthew xie: api 18, no. we don't do advertisement. we do scanning for theadvertisements. so we are in the centralrole, basically.
so one, the broadcaster roleor the observer role that you're talking about, thatdoesn't really apply to us, because we have tx and rx. we have both tx rx. does that answeryour question? scout sinclair brody: maybe thisis something that we can continue during officehours, if that's ok. can you make it tooffice hours? audience: ok.
matthew xie: so in short, wedo central, and that's it. with central, we can scanadvertisements. so you have observer there,supporting it in default, too. no broadcaster or peripheralat this point for api 18. audience: thank you. scout sinclair brody: thanks. let's move over here. audience: hi, myname is diego. i work for a company that doesmultiple mobile platforms.
is this going tobe available-- is this going to work also withother platforms like ios or windows phones that alreadysupport bluetooth 4.0? scout sinclair brody:well, so it depends. i'm actually not familiarwhether or not those devices support the peripheral role. because in android api version18, we only support the central role. so if they can do peripheral,then we can talk to them.
but if they only do central aswell, then as of api 18, no, you won't be able to talk overble with the devices. basically, you need somethingthat can be in peripheral mode. audience: thanks. audience: hello. i was curious about aptx or "aptx", higher dynamic range bluetooth streaming audio. is that going to besupported in aosp?
or is that just relegated tosamsung, htc, and others that pay a license fee? i'm just curious. scout sinclair brody: so asfar as i know, that's not something that we have workingfor this next version. and in general, we don't commenton things that are happening after that. so definitely stop by officehours to talk about it and make sure that we understandyour use cases and what you
envision this beinguseful for. because it can be useful forus in sort of prioritizing what features and what aspectsof the spec we go for next. but at this point, we won'tcomment on things like that. sorry. all right. i guess one more overhere, and then we head to office hours. audience: this is justa curiosity.
the ios bluetooth stackrotates mac addresses every 15 minutes. does the android stack doanything like that? it's a privacy feature,currently. matthew xie: i think we do. we do that, yes. audience: and, just curious. what type of range have youguys seen on android's peripheral?
like, how many feet? richard hyndman: havewe tried that? mine works from hereto here quite well. audience: six inches? twelve inches? matthew xie: more than that. i think it's-- scout sinclair brody:obviously it depends on the device.
matthew xie: yeah, it dependson the device. about ten meters, i would say. audience: so onelast question. the rssi, is that going to benormalized across devices? so if i have two devices, like asamsung and an htc, and they both report, say, at an rssi of85, would they be about the same distance? or is it calibrated per deviceor per radio [inaudible] or something?
matthew xie: that'sa good question. i think it's calibrated. audience: that would be greatfor the cts or whatever, to make sure that those areconsistent, because otherwise we'd have to checkit manually. thank you. scout sinclair brody:makes sense. all right, on to office hours. thank you all for your time.
richard hyndman: the officehours is on the third floor, at the back of theandroid area. thanks very much. matthew xie: thank you.
