tree 1304f6cac5975236e0920624c6658bfd40e205b9
parent 6dc3f4e553d333b9f115a222a9a684bb2aa55b5e
author Nick Pelly <npelly@google.com> 1255366479 -0700
committer Nick Pelly <npelly@google.com> 1255368385 -0700

Delay 500ms between each registering each SDP record using sdptool.

This is to workaround an issue where SDP records will fail to register using
sdptool. When we run SystemService.start() it forks sdptool, so if we do this
four times in a row these forked processes can run in parallel, and one or
more of them fails. There is probably some thready safety issue in sdptool
or Bluez that makes it unsafe to run sdptool in parallel.

As a workaround, delay 500ms between each run of sdptool to register SDP
records when starting Bluetooth.

Before this fix it was easy to reproduce problems with service record
registration. If you turn BT off/on multiple times you can see that sometimes
one or more service records are missing. Repro rate is about 20% in my tests.
Result is that remote devices cannot connect to the missing service.

After this fix I am unable to reproduce any missing SDP records, after 30+
cycles of BT on/off. Motorola BT team also ran stress tests overnight with this
fix and were unable to reproduce the missing SDP records.

This is a low risk fix. It does delay some records from being registered
by an additional 1.5 seconds (on top of the 3 second delay we already had),
so if you try and very quickly connect a BT service after turning BT on it
won't work the first time.

Do not merge. (I will use a less hacky fix for MR2/Master)

Change-Id: I305c181c3194e8ce25e3825320cc2e1ef6d3d3cc
Bug: 2180800
DrNo: eastham
Joke: Why can't you play cards in the jungle? Because there's too many cheetas!