Можно определить версию и билд ява-машины девайса?

а зачем  тебе это нужно?

Для девайсов, где Java встраиваемая эта версия никак не коррелирует с JDK версиями (потому что не только Sun машину используют,как правило в основном не Sun машину встраивают  ), ну и вытащить ты это дело не сможешь.
Для смартфонов, куда ты можешь ставить Java машину, ты можешь это посмотреть, но для чего?

Это нужно, чтобы удостовериться, что проблема не в коде, не в девайсе, а именно в реализации библиотечной функции.

сделай тестовый мидлет и прогони его. То как реализуют библиотечную функцию при портировании KVM в телефон - это "страшное дело" , помимо того, что будет вызываться в нативе ещё есть и фреймворк, который производитель девайса может сделать самостоятельно и уже потом в этом фреймворке дёргать ту самую библиотечную функцию. 
Опиши что именно тебе нужно (классы, методы, передаваемые параметры, что ожидаешь получить и т.д.), может помогу тестик накатать. (можешь в приват, если светиться не хочешь)

Вообщем, это не такой уж и секрет - пусть все знают   

Схематично проблема выглядит так:

в цикле считывается информация с GPS - приемника. Через 5 сек.(SE M600) - 5 мин.(SE P990) происходит блокировка функцией read(...). Почему? GPS - приемник при этом включен. Дело в девайсе? На остальных тестируемых девайсах такой проблемы не наблюдается. Если хоть бы таймаут можно было устанавливать, после которого блокирующая функция read(...) бросает Эксцепшн, а то этого тайм-аута уж слишком долго приходится ждать. Так что   

Я думаю, что как-то вот так. Писалось не коленке , так что сильно не ругайтесь.
То есть, читаешь каждый раз что-то заводишь таймер, если следующее чтение происходит раньше чем таймер истечёт, то таймер устанавливается новый. В таймер должна быть проверка на то, в каком состоянии мы сейчас находимся, на момент, когда таймер сработал. Если в состоянии чтения, то значит что-то пошло не там и мы тут повисли. (как и что тебе в этой ситуации предпринимать, думаю ты сам уже давно решил )
Где-то в другом месте далаешь вызовы MyClass.readData() по необходимости. (ну или как-то так. думаю принцип понятен)

в этом-то и вся загвоздка: если прервать тред, в котором произошла блокировка, то подсоединиться к GPS-у уже неудастся, т.к. открытое соединение нужно вначале закрыть. А как его закрыть, когда оно занято блокирующей функцией read()?

всё в null, и при следующем обращении, делай заново коннекшн.
Connection у тебя должен быть один единый, если он null, то значит его сначала нужно открыть, если уже есть, то брать из этого коннекшена InputStream.

Что в null? StreamConnection cn ?
Если его ставить в null, а потом делать коннект, то вылетает Эксцепшн с информацией о том, что коннекшн уже открыт. Закрыть же его не удается, т.к. соединение занято(функция read() не отпускает).

Если же StreamConnection cn , то и здесь выпадает java.io.IOException.

  

Проблема решена.
Блокировка происходит из-за переполнения Bluetooth-буфера девайса. Оказывается отправка происходит за плечами программиста! Если делать 

после 

то все работает.

Другое дело, что skip(128) данных мне не подходит, но это уже совсем длугая история