JustaJumbo

Давайте попробуем понять, как это предотвратить и не превратить шлем в кирпич.
 
Данный способ работает как на новых, так и на не очень новых шлемах.
 
Прежде всего следует иметь в виду главное - если у вас прошивка достаточно старая, нельзя обновляться сразу на версию v72. Ни по воздуху, ни вручную. И даже на v71 со старой прошивки сразу обновляться не рекомендуется.
Безопасно обновляться на v72 можно только c прошивки v71. Со всех других старых версий на v72 обновляться нельзя, иначе с большой вероятностью угробите шлем. Соответственно, чтобы не окирпичит шлем, нужно постепенно подогнать прошивку на версию v71, а затем уже можно прошиваться на последние версии.
 
Пока достоверно неизвестно, какую именно прошивку считать достаточно старой для этого, поэтому чтобы максимально избежать рисков окирпичивания, следует обновляться последовательно.
Еще нужно помнить, что с версии v51 система Андроид в шлеме перешла с v10 на v12. 
А также то, что с версии v76 Мета снова обновила Андроид и теперь v14.
 
Чтобы не загрузилось последнее обновление, которое убьет вам шлем, крайне желательно отключить автоматическое обновление.
Это можно сделать через программу Quas (пункт 1) или командой adb:
 
adb shell pm disable-user --user 0 com.oculus.updater И уже можно не волноваться о том, что внезапно прилетевшая прошивка приведет ваш шлем в негодность.
 
Update: Обновления можно не отключать, Мета отозвала прошивку v72 и она больше не раскатывается автоматически.
https://communityforums.atmeta.com/t5/Talk-VR/NOT-SOLVED-Unacceptable-Response-to-Software-Update-Breaking/m-p/1277052#M399111
 
Но проблема получения бутлупа при обновлении сразу через несколько версий существовала и до этого случая, так что рекомендация все еще актуальна.
 
Итак, рекомендации о том, как следует поступить при прошивке:
 
Допустим, у вас на шлеме прошивка v32 (или любая от v21 до v49), тогда ее следует обновить до версии v50, затем прошить шлем на v51. Далее можно пперепрыгнуть сразу на несколько версий и прошить v67. После этого шлем прошить версией v71, чуть выдохнуть и дать шлему прошиться по воздуху до  более высоких версий (v74 и выше) или сделать это вручную.
 
Иногда пррошивки не встают как задумано, то есть, допустим, у вас v56, вы пробуете шить v67 и она не шьется, срывается на 47% или выдает Total xfer 1.00x -
в этом случае пробуйте шить соседние - v68 или v66. 
 
Узнать номер прошивки своего шлема можно утилитой Quest Firmware Viewer, но для ее работы нужен включенный Режим разработчика.
Если Режим разработчика отсутствует, то узнать номер прошивки можно из Расширенного рекавери: при включении шлема держать кнопку Громкость плюс, пока не появится сломанный Андроид. Затем удерживая кнопку Питание, кратко нажать кнопку Громкость плюс. Появится желто-синее меню, и одной из верхних строчек будет видно несколько цифр. Идем на сайт прошивок и сравниваем 17-значное число версии среды с номером прошивки.
 
Но проще использовать все тот же Quas - загрузите шлем в режим Bootloader, подключите его кабелем к ПК и запустите Quas.
Он автоматически определит, что шлем в бутлоадере и вывесит специальное меню. В нем вам потребуется пункт K. Информация о прошивке шлема, слотах загрузки, ревизии и батарее.
Выбираете его и ждете выводаинформации. Там и будет информация о версии прошивки.
 
Есть достаточно достоверные сведения, что вполне безопасно накатывать версию 71.0.0.527.522.662446962 на любую старую прошивку.
Проверено неоднократно, на многих шлемах, в том числе новых, то есть тех, у которых версия прошивки v38.
Но прошивать или нет сразу на эту версию - решать только вам.
 
Прошиваем шлем:
 
Этот метод предназначем только для особых случаев, когда шлем в режиме первичной настройки со старой прошивкой и в Виртуальное окружение загружен быть не может, а значит обновиться сможет по воздуху. 
В этом случае при обновлении он накатит последнюю прошивку , а значит есть риск окирпичить шлем, если на нем очень старая версия.
 
Идем на сайт с прошивками, скачиваем необходимые версии. Скачиваем программу Quas Кладем файл с прошивкой рядом с этой программой и переименовываем его в update.zip Если шлем выключен, включаем его (жмем кнопку Питание), удерживая кнопку Громкость минус. В шлеме открывается т.н. Бутлоадер - USB Update Mode. Светодиод станет оранжевым. Подключаем шлем кабелем к ПК. Экран может потухнуть, и если это случилось просто однократно нажмите кнопку Питание, экран включится и снова покажет меню USB Update Mode. Кнопками громкости листаем до опции Sideload Update и кнопкой Питание подтверждаем выбор этой опции. Экран погаснет а светодиод станет белым. Запускаем программу Quas, она определит что шлем в режиме Sideload и напишет об этом. Жмем на ПК кнопку F, начнется процесс прошивки, светодиод станет фиолетовым. После завершения прошивки шлем автоматически перегрузится.  
Если шлем новый, начнется процесс активации. Если уже был активирован, то загрузится в Виртуальное окружение.
 
Прошить шлем можно и из Виртуального окружения:
Первые три пункта как в предыдущем способе.
4. Подключаем шлем кабелем к ПК
5. Запускаем Quas
6. Жмем G - A.
7. Следуем инструкции.
 
Если шлем не определяется или нет драйверов, Квас об этом сообщит. В этом случае также следуем инструкциям программы. 
 

Итак, для нечала, как всегда, преамбула.
 
В среде Андроид имеется встроенная система бэкапа приложений, и с помощью adb ее можежно запустить так:
adb backup -f <имя архива> -noapk -noobb <название пакета приложения> Как видно из строки, в данном случае бэкапятся только данные. Ни apk файл, ни obb не входят в бэкап, но мы их можем вытащить и обычным образом. Ну, почти обычным.
Вот этим мы и воспользуемся, а затем просто расковыряем файл архива и вытащим из него вожделенные сейвы.
Все что ниже - просто пример, но его можно использовать. Возьмем игру Resident Evil 4 и на ней покажем этот способ. Для вытаскивания сейва нам понадобится узнать имя приложения, это можно сделать массой вариантов, один из которых Quas - пункты J - D - 2 - 3.
Программа выведет список неофициальных приложений, среди которых будет искомое:
 

 
Таким образом, название пакета приложения - com.Armature.VR4
 
А далее уже непосредственно амбула, то есть батник, каждая строка которого прокомментирована и рассказывает для чего и почему.
Весь нижеследующий текст можно поместить в cmd файл и запустить на ПК, в итоге рядом с батником появится каталог apps, в котором будет каталог с названием приложения, содержащий распакованные данные, в котором и лежат сейвы.
 
@echo off rem Сюда вписываем название пакета приложения. В данном случае так называется пакет игры Resident Evil 4. set packagename=com.Armature.VR4 rem В этой строке название архива, оно может быть каким угодно с раширением .ab set archivename=re4.ab rem Имя скрипта, в котором лежат команды, выполняемые шлемом. Также какое угодно название. set shscriptname=dataextract.sh rem Запуск встроенной архивации данных. В шлеме всплывет окно, в котором следует нажать кнопку Создать резервную копию. adb backup -f %archivename% -noapk -noobb %packagename% rem Строка, распаковывающая архив бэкапа @echo ^( printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" ; tail -c +25 /data/local/tmp/%archivename% ^) ^|  tar xfvz - -C /data/local/tmp/>%shscriptname% rem Отправляем архив бэкапа в шлем adb push %archivename% /data/local/tmp/ 1>nul rem Отправляем скрипт в шлем adb push %shscriptname% /data/local/tmp/ 1>nul rem Корректируем срипт для среды Андроид adb shell dos2unix /data/local/tmp/%shscriptname% rem Выполняем скрипт на шлеме с сохранением результатов в лог файл adb shell sh /data/local/tmp/%shscriptname% >log.txt 2>nul rem Вытаскиваем распакованный архив из шлема adb pull /data/local/tmp/apps %cd% rem Подчищаем все файлы, которые мы загоняли в шлем adb shell rm -R /data/local/tmp/ 1>nul 2>nul pause  
Один нюанс - батник следует запускать с надетым на голову шлемом, то бишь вслепую жмакнуть Enter, поскольку всплывшее окно про Создать резервную копию имеет свойство исчезать. Если так случилось, просто запустите батник снова.
 
Проверил и на игре In Death - все прекрасно работает, вот лог того, какие данные вытаскиваются:
 
Вот еще бы автоматически нажимать кнопку "Создать резервную копию данных"...
Пробовал adb shell input tap 380 760 (цифры - координаты кнопки в окне создания бэкапа), но увы, не нажимается она. Координаты считываются нормально, а вот сэмулировать нажатие лучом контроллера не получается.
 
К сожалению, вынужден немного огорчить - слить сейвы это только половина дела, другая половина - закинуть их обратно, на место имеющихся, что тоже нетривиальная задача, над которой надо подумать. Если будут результаты, то уже в следующей серии.
 
А пока можно пользоваться встроенным восстановлением Андроид, у нас же файл бэкапа сохраяется.
Это делается вот таким простым батником:
rem Название архива бэкапа set archivename=indeath.ab rem Команда восстановления adb restore %archivename% pause  
После запуска появится такое же окно Андроид как и в первом случае, только нужно будет нажать кнопку "Восстановить данные".
 
А чтобы не путаться в бэкапах, поделюсь одним хинтом - можно в первый батник добавить время и дату к имени файла.
Вот таким образом:
 
set dt=%date:~0,2%.%date:~3,2%.%date:~6,4% set tm=%time:~0,2%-%time:~3,2%-%time:~6,2% set tm=%tm: =0% echo %dt%_%tm%  
По желанию можно использовать либо время, либо дату, а можно и то и другое вместе и в любом порядке.
 
ЭВРИКА!!!!
 
Что означает - нашел! А нашел вот что - после восстановления бэкапа стандартным способом (то есть - встроенным в Андроид механизмом), файлы сохранений становятся перезаписываемыми:

 
Иными словами достаточно стягивать бэкапы способом выше, через скрипт, и пусть себе лежат до тех пор, пока не понадобится их восстановить. 
 
И как только сей момент наступит, делаем ход конем - играем до мента создания сейва (на любом начальном этапе, главное чтоб сейв создался), затем бэкапим встроенным способом, тут же восстанавливаем этот бэкап тем же встроенным механизмом, а далее накатываем наши забэкапленные сейвы в шлем каким угрдно способом - через TC  с плагином ADB или прямой командой aADB - неважно, главное что теперь их можно вернуть обратно. А стянуть - вон выше скрипт, работает безотказно.
 
Но в этом случае все-же следует помнить одну вещь: следующее сохранение в игре установит файлам сейвов все тот же запрет на чтение, так что не уходите далеко от скрипта, он еще пригодится.
 
Решение найдено и опубликовано в соседней теме. Теперь бэкапы создаются и восстанавливаются полностью автоматически.
 
Итак, обновленная и окончательная процедура, автоматически создающая бэкап данных:
@echo off set packagename=com.Armature.VR4 set archivename=re4.ab rem set packagename=com.rockvr.moonplayer rem set archivename=mvp.ab rem set packagename=com.vertigogames.azs2 set noapk=no set noobb=no set shscriptname=dataextract.sh adb shell am broadcast -a com.oculus.vrpowermanager.prox_close 1>nul 2>nul adb shell input keyevent 224 @start /min "" adb backup -f %archivename% -%noapk%apk -%noobb%obb %packagename% 1>nul 2>nul @echo Bckup started.. timeout 2 1>nul adb shell input keyevent 61 ping localhost -n 1 1>nul adb shell input keyevent 61 ping localhost -n 1 1>nul adb shell input keyevent 61 ping localhost -n 1 1>nul adb shell input keyevent 66 @echo Creating backup... call :_CheckBackupProcess @echo Extracting data from backup file... @echo ^( printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" ; tail -c +25 /data/local/tmp/%archivename% ^) ^| tar xfvz - -C /data/local/tmp/>%shscriptname% adb push %archivename% /data/local/tmp/ 1>nul 2>nul adb push %shscriptname% /data/local/tmp/ 1>nul 2>nul adb shell dos2unix /data/local/tmp/%shscriptname% 1>nul 2>nul adb shell sh /data/local/tmp/%shscriptname% >log.txt 2>nul adb pull /data/local/tmp/apps %cd% 1>nul 2>nul adb shell rm -R /data/local/tmp/ 1>nul 2>nul adb shell am broadcast -a com.oculus.vrpowermanager.automation_disable 1>nul 2>nul del /q /f %shscriptname% 1>nul 2>nul rem Эту строку можно закомментировать и тогда файл бэкапа re4.ab удаляться не будет. del /q /f %archivename% 1>nul 2>nul @echo Done. pause exit :_CheckBackupProcess @for /f "tokens=1,2,3 delims=:= " %%a in ('adb.exe shell dumpsys activity activities ^| findstr /i /c:"taskAffinity"') do ( if [%%c] == [com.android.backupconfirm] (timeout 2 >1 && goto _CheckBackupProcess) else (exit /b) )  
В процедуру добавлен цикл, проверяющий окончание создания бэкапа.
Пока без комментариев, добавлю позже.
 
А это батник, восстанавливающий бэкап обратно на шлем:
@echo off rem Вписываем имя файла бэкапа, который нужно восстановить set archivename=re4.ab @adb shell am broadcast -a com.oculus.vrpowermanager.prox_close 1>nul 2>nul adb shell input keyevent 224 @start /min "" adb restore %archivename% timeout 2 1>nul adb shell input keyevent 61 ping localhost -n 1 1>nul adb shell input keyevent 61 ping localhost -n 1 1>nul adb shell input keyevent 61 ping localhost -n 1 1>nul adb shell input keyevent 66 call :_CheckBackupProcess adb shell am broadcast -a com.oculus.vrpowermanager.automation_disable 1>nul 2>nul echo Done. pause exit :_CheckBackupProcess @for /f "tokens=1,2,3 delims=:= " %%a in ('adb.exe shell dumpsys activity activities ^| findstr /i /c:"taskAffinity"') do ( if [%%c] == [com.android.backupconfirm] (timeout 2 >1 && goto _CheckBackupProcess) else (exit /b) )  
После восстановления файлы в каталоге Android/data/com.Armature.VR4 будут доступны для копирования на ПК с помощью стандартной команды adb:
adb pull "/sdcard/Android/data/com.Armature.VR4" %cd%  
Собственно говоря, с методикой автонажатия кнопок распаковка бэкапа уже не так чтоб имеет смысл, разве что вам захочется иметь отдельные файлы сейвов. 
 

Пока коллекционирую банальности и изобретаю велосипеды.
Подумал тут: "Если с контроллерами геморно через АПИ, что можно сделать без них?"
Тапы шлем, действительно не слышит: из инпутов есть только разъем наушников, да кнопки питания с громкостью. Тачскрин (INPUT_PROP_DIRECT) как бы тоже есть, но по ивентам судя, он не координатный - "одна большая кнопка". 
$ ls -l /dev/input crw-rw---- 1 root input 13,  64 1970-05-04 21:16 event0 crw-rw---- 1 root input 13,  65 1970-05-04 21:16 event1 crw-rw---- 1 root input 13,  66 1970-05-04 21:16 event2 crw-rw---- 1 root input 13,  67 2024-07-07 09:07 event3 crw-rw---- 1 root input 13,  68 2024-07-08 02:00 event4 $ getevent -lp add device 1: /dev/input/event4   name:     "Device 0x4CBCE9E9E8D710A4"   events:     KEY (0001): KEY_FORWARD   input props:     INPUT_PROP_DIRECT add device 2: /dev/input/event3   name:     "anorak-max98388-snd-card AK4333 Headphone"   events:     SW  (0005): SW_HEADPHONE_INSERT   SW_LINEOUT_INSERT     SW_JACK_PHYSICAL_INS   input props:     <none> add device 3: /dev/input/event2   name:     "pmic_resin"   events:     KEY (0001): KEY_VOLUMEDOWN   input props:     <none> add device 4: /dev/input/event1   name:     "pmic_pwrkey"   events:     KEY (0001): KEY_POWER   input props:     <none> add device 5: /dev/input/event0   name:     "gpio-keys"   events:     KEY (0001): KEY_VOLUMEUP   input props:     <none> И главное, при снятии шлема окна пропадают, точнее сворачиваются в угол, если правильно понял изменения range.

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