Нее, это все неинтересно. BCM4774 - целый монстр-контроллер, который включает wifi, bt
и datafusion от всяких сенсоров, от него бы на самом деле внутреннюю прошивку поиметь неплохо,
но для этого надо покупать довольно дорогой смартфон
На ублоксовском форуме задают забавные вопросы типа https://forum.u-blox.com/index.php?qa=7625&qa_1=about-dynseed-and-fixseed
дроны они наверное спуфить собираются
Navilock собирается “в ближайшее время” выпустить приемники серии NL-82022MP http://www.navilock.com/produkte/N_62755/merkmale.html?setLanguage=en
на базе NEO-M8U (урезанный DeadReckoning без внешних данных wheeltick, но с акселерометром+гироскопом Bosch BMI160).
Доступа к сырым GPS данным и прошивке там конечно нет
должен “освободить” память под массивом, являющийся частью navigationMessage ?
На Mate 9 Galileo raw data работает, но как-то не очень здорово. Вот пример сырых данных для E14
I/NAV не видел, и это видимо связано с проблемой navigationMessage.
EGNOS тоже почему-то не дает никаких сырых данных, а Beidou я пока не пробовал:
для этого надо редактировать конфигурационный XML gps4774config.xml на readonly диске ( EnableBeidou=“true”)
Про C++ что ли?
Использование JNI требует аккуратности, как и всё остальное в мире C/C++.
Должен удалить локальную ссылку, сделав доступным объект для garbage collection. Проблема не в нём, а в методе JavaObject::callSetter:
template<>
void JavaObject::callSetter(const char* method_name, uint8_t* value, size_t size) {
jbyteArray array = env_->NewByteArray(size);
env_->SetByteArrayRegion(array, 0, size, (jbyte*) value);
jmethodID method = env_->GetMethodID(
clazz_,
method_name,
"([B)V");
env_->CallVoidMethod(object_, method, array);
}[/code]
При вызове NewByteArray создаётся локальная ссылка (array), но потом нигде не удаляется. При вызове из Java это не страшно, т.к. таблица локальных ссылок при возврате в Java очищается, а вот во всяких callback-механизмах это порождает утечки памяти.
OK, что делать ™ ? Написать логгер на c++ тоже будет непросто, хотя и по другим причинам.
Интересно, что все гуглопримеры по доступным ссылкам относятся к Qualcomm, а не к BCM477*, и везде показывают только “Raw” и нигде
“Nav”:
Ее конечно можно и для 7.0.0 попытаться пересобрать с патчем, или же пытаться пропатчить сам бинарник.
В любом случае надо еще разблокировать ‘readonly’ для /system (методы предлагаемые на xda-developers.com у меня не работают)
А финт, если либу положить в сборку APK и она загрузиться первой. А то и вовсе может быть возможно переназначить этот вызов на свой JavaObject::callSetterFix. По крайней мере при сборке на обычном С++ бывает ругается, что существуют две реализации и он выбирает какую-то одну.
Вообще андроид странный, я 4 месяца пытался собрать rtkgps+, чтобы он не падал на моём телефоне. И вот недавно я выяснил причину, что в java и в нативном коде массивы которые копировались друг в друга были разной длинный. Но на моём андроиде копирование молча падало в дебрях системы, на на более новых нет, и как бы работало О_о
Так же спасибо Sergey Astakhov, твои unix сокеты пригодились.
П.С. Так же я узнал секрет, как на андроиде записывать логи с приёмника с timetag-ом, что бы потом их можно было повторять в rtknavi - надо в конце имени файла добавить ::T
Я все-таки снес стандартную прошивку, и заменил ее на самопал
Теперь все read-write. GPS не работает по следующей причине
[ 16.240081s][pid:1,cpu4,init]init: (Parsing /init.connectivity.gps.rc took 0.00s.)
[ 18.029235s][pid:1,cpu7,init]init: Starting service 'gpsdaemon'...
[ 19.310211s][pid:1,cpu4,init]init: Service gpsd_4774 does not have a SELinux domain defined.
[ 19.696044s][pid:1,cpu6,init]init: Service 'gpsdaemon' (pid 459) exited with status 0
В /sepolicy gpsd_4774 действительно нет, в /property_contexts есть
ctl.gpsd_4774 u:object_r:gpsd_prop:s0
а добавить контекст в init.connectivity.gps.rc
service gpsd_4774 /vendor/bin/glgps4774 -c /data/gps/gpsconfig.xml
socket gps seqpacket 660 gps system
class late_start
user gps
group system inet sdcard_rw wakelock
disabled
не удается, так как при перезапуске он заменяется на версию из какого-то ramdisk.
При этом в ramdisk из boot.img такого файла нет (???)
В телефоне до хрена partitions, везде бекапы, резервные копии, логи.
Никакого ЦРУ не надо, китайцы какие только данные по дискам не распихали
Этот glgps4774 еще через AtCmdTransportPort=“/dev/appvcom9”
посылает телефону магические команды.
В SuplTlsCertPath=“/data/cust/xml/server.pem” никакого сертификата нет.
При этом есть запароленная пара
/vendor/etc/gnss/config/gnss_lss_slp_thirdparty.p12
и запароленный ключъ
/vendor/etc/gnss/config/gnss_lss_rfg_key_thirdparty.pem
Интересно кто и для чего ими пользуется. Пароль же тоже должен где-то
лежать.
cacert_location.pem и xtra_root_cert.pem отсутствуют.
Нашел, где находится используемый ramdisk.cpio.gz,
он в сборке .img на /dev/block/sdd32 с характерным названием boot_a
Также полностью пересобрал AOSP (7.0.0_r30) для generic_arm64 из исходников.
blackbox на openlog для сбора треков на веле? Или там только координаты идут наружу и сырые данные не получить?
Сейчас пишу треки телефоном, для “разбора полётов”.