Zablokowana prędkość w lancherze

Krótki opis

 W niektórych nakładkach (lancher-ach) wyświetlana jest na ekranie głównym prędkość. Zazwyczaj pobierana jest ona z aplikacji CanAllInOne (Mój Samochód, CarInfo). Zazwyczaj po wejściu w zakładkę Status w "Informacje o samochodzie" i powrocie do Lanchera prędkość zostaje zamrożona i nie zmienia się. Nie jest to błąd, ani awaria radia. Jest to problem z komunikacją między aplikacjami. W zależności od oprogramowania stacji czasami mamy wybór źródła informacji: CAN lub GPS. W przypadku wyboru GPS prędkość jest prawidłowa (choć też nie zawsze), ale w przypadku wyboru CAN prędkość zostaje zamrożona. Problem dotyczy nakładek dołączonych do stacji multimedialnych lub tworzonych bezpośrednio pod te urządzenia przez ich producentów. Komercyjne nakładki uniwersalne pod różne platformy, zazwyczaj nie dają możliwości wyświetlania prędkości z CAN. Nie reagują na zmiane źródła (CAN lub GPS). Zmiany takiej możemy dokonać w ustawieniach aplikacji Mój Samochód (My Car), daje ona dostęp do ukrytych funkcji CanAllInOne (Informacje o samochodzie), która zajmuje się m.in. komunikacją z szyną CAN. Znajdują się tam również inne opcje niedostępne nigdzie, nawet w menu fabrycznym.

Naprawa doraźna bez ingerencji w pliki

 Wracając do tematu, aby naprawić problem, niezależnie od wersji aplikacji Lancher oraz CanAllInOne, musimy wykonać kilka czynności. Nie musimy resetować radia, nie musimy czyścić pamięci podręcznej oraz danych w żadnej aplikacji, to i tak zazwyczaj nie pomoże. Natomiast należy jeszcze raz wybrać model protokołu szyny CAN – model pojazdu (standardu danych z szyny CAN), czyli po prostu kliknąć na niego lub zmienić na inny model zbliżony – z takim samym kodowaniem. Dostaniemy komunikat: „Wybór modelu jest pomyślny, a aplikacja zostanie automatycznie zamknięta i ponownie uruchomiona po trzech sekundach”. To tyle, natychmiast w Lancher prędkość jest pokazywana prawidłowo i wyświetlane są jej zmiany. Musimy po tej czynności wrócić do ekranu głównego lub w inne miejsce gdzie nie wyświetlane są dane z "Informacje o samochodzie". Jeśli wejdziemy znowu w CarInfo zakładka "Status" i wrócimy do Lancher, znowu prędkość zostanie zamrożona. Trzeba od nowa wybrać model protokołu szyny CAN. Jest to sposób doraźny, a nie stale naprawiający sytuację.
 Jak dostać się do menu wyboru protokołu CAN? Możemy to zrobić na dwa sposoby (oba prowadzą w to samo miejsce – są to skróty – odnośniki):
1. Poprzez dodatkową aplikację, jeśli ją mamy zainstalowaną: „Mój Samochód” (My Car), zakładka „Diagnoza” (Diagnosis), przycisk „Wzór” (Car).
2. Poprzez „Ustawienia Radia” (CarSettings), ustawienia systemowe (System Settings), ustawienia fabryczne (Factory Setting), ustawienia fabryczne (Factory Setting), CAN Type Set, Can Type Set.
3. Przez aplikację CanSetting: Przejdź do aplikacji →.

Analiza i rozwiązanie problemu zamrażania (zawieszania się) prędkości Speed Freeze

 Dla przypomnienia, problem polegał na zamrażaniu wskazań prędkości na ekranie głównym stacji multimedialnej (w aplikacji Launcher) po każdorazowym wyjściu z aplikacji CarInfo - Informacje o samochodzie (CanAllInOne). Prędkość przestawała się aktualizować, pokazując ostatnią zapamiętaną wartość, a po restarcie urządzenia widniało stałe 0 km/h. Co istotne, w samej aplikacji CarInfo dane o prędkości zawsze były wyświetlane prawidłowo, co sugerowało błąd w sposobie przekazywania lub interpretacji danych przez nakładkę graficzną.

Nieudane próby naprawy

Przed znalezieniem ostatecznego rozwiązania sprawdzono szereg hipotez, które nie przyniosły trwałego efektu:

• Czyszczenie danych i pamięci podręcznej: Działało jedynie doraźnie i nie rozwiązywało przyczyny problemu .
• Modyfikacja ustawień systemowych: Zmiana kluczy konfiguracyjnych takich jak speed_source czy obd_speed nie korelnowała z występowaniem błędu.
• Odświeżanie subskrypcji w Launcherze: Przeprowadzono 17 iteracji poprawek (m.in. mechanizmy rebind i watchdog), które miały "wymusić" odświeżanie danych, jednak Launcher nadal otrzymywał dane w nieczytelnym dla niego formacie.
• Zmiany w serwisie CarInfo: Próby modyfikacji cyklu życia serwisu (np. usunięcie restartu w onDestroy) prowadziły do natychmiastowych błędów i zamykania się aplikacji.
• Modyfikacje Lanchera (nakładki): Liczne próby nie rozwiązywały problemu. Podejmowane działania:
  1. Odświeżanie subskrypcji CAN: Stosowano sekwencję unRegister -> register (wyrejestrowanie i ponowna rejestracja callbacków), szczególnie w klasie CanSpeadWidget w metodach init i onResume.
  2. Modyfikacje mechanizmu komunikacji AIDL: Próbowano wdrożyć AIDL backport oraz mechanizm hard rebind (twarde ponowne powiązanie z usługą serwera CAN).
  3. Mechanizmy nadzoru i stabilizacji: Implementowano funkcje typu watchdog, bramki rejestracyjne (registration gate) oraz mechanizmy timeout/cooldown, które miały zapobiegać problemom wynikającym z nagłej zmiany stanu aplikacji (lifecycle).
  4. Zarządzanie stanem obiektów: Podejmowano próby wykonania soft-resetu singletonu (CanAppRemoteManager)
  5. Czyszczenie danych: Doraźnie testowano czyszczenie pamięci podręcznej i danych aplikacji Launcher, co jednak nie przynosiło trwałych efektów
  Ostatecznie uznano te próby za nieudane, ponieważ problemem nie był sam mechanizm subskrypcji w Launcherze, lecz format danych przesyłanych przez MCU po przełączeniu się w tryb SLOW, których Launcher nie potrafił zinterpretować

Rozwiązanie problemu i współpraca aplikacji

 Skuteczne rozwiązanie udało się wypracować dzięki szczegółowej diagnostyce runtime oraz analizie protokołu komunikacyjnego między stacją a modułem MCU (CAN box).

• Stabilizacja bazy (CarInfo): Pierwszym kluczowym krokiem było umożliwienie bezpiecznej modyfikacji aplikacji CarInfo. Poprzez usunięcie parametru sharedUserId z manifestu, wyeliminowano ryzyko wystąpienia pętli restartów systemu (bootloop) po reinstalacji zmodyfikowanej wersji.
• Identyfikacja Root Cause: Odkryto, że moduł MCU (firmy Rise, modele RZ-VW08/VW58) posiada dwa wzajemnie wykluczające się tryby pracy:
  1. Tryb FAST - raw CAN frames: Dane płyną co ok. 400ms – ten tryb jest niezbędny dla płynnego działania prędkości w Launcherze.
  2. Tryb SLOW - parsed packets: Dane płyną co ok. 2000ms – tryb ten dostarcza pełnych danych do zakładki Status w CarInfo (napięcie, temperatura itp.).
  Analiza wykazała, że wejście w zakładkę Status wysyłało komendę 0x41 (HOST_SETTING), która na stałe (w pamięci NVRAM modułu) przełączała MCU w tryb SLOW. Launcher nie potrafił poprawnie interpretować danych w tym formacie, co powodowało efekt "zamrożenia".
• Wdrożenie poprawki (NOP Fix): Aby zapobiec przełączaniu trybu, zidentyfikowano 5 wariantów sterowników dla pojazdów VW (klasy IReqDataListener). W ich kodzie źródłowym, w metodach odpowiedzialnych za żądanie danych (onReqData), zastosowano instrukcję NOP (zamiana logiki na pustą operację return-void).
• Efekt końcowy: Dzięki zablokowaniu komendy 0x41, moduł MCU pozostaje na stałe w trybie FAST. Pozwoliło to na pełną i stabilną współpracę obu aplikacji – prędkość w Launcherze jest teraz wyświetlana płynnie i nie zawiesza się, nawet po wielokrotnym korzystaniu z funkcji CarInfo.

Aplikacja CarInfo została ustabilizowana, co pozwala na jej bezpieczne używanie, a Launcher odzyskał pełną funkcjonalność prędkościomierza opartego na szynie CAN.

Dodatkowa korzyść: poprawne wskazania temperatury zewnętrznej

 W wyniku wprowadzonych zmian, oprócz naprawy wyświetlania aktualnej prędkości, dodatkowo udało się uzyskać rozwiązanie problemu zawieszonych wskazań temperatury zewnętrznej w Launcherze. Wcześniej, poprawne dane te były dostępne tylko w zakładce Status aplikacji CarInfo. W Lancherze niezależnie od zmian wartości, cały czas widniała temperatura odczytana ze wskazań w momencie wejścia do zakładki Status w CarInfo. Teraz, dzięki utrzymaniu trybu FAST, temperatura jest odczytywana i aktualizowana na ekranie głównym stacji multimedialnej.

Dlaczego temperatura działała tylko w zakładce Status?

Zgodnie z dokumentacją, moduł MCU w urządzeniu posiada dwa tryby pracy, które rzutowały na oba wskazania:

• Tryb Parsed packets (SLOW): Jest to tryb aktywowany komendą 0x41, gdy wchodzimy w zakładkę Status. W tym trybie MCU sam pakuje pakiety danych i wysyła gotowe wartości, m.in pełne dane takie jak temperatura zewnętrzna, napięcie czy zużycie paliwa.
• Objaw: Dlatego właśnie temperatura aktualizowała się tylko wtedy – bo tylko w tym trybie MCU wysyłało do systemu Android gotową, odświeżoną informację o temperaturze.

Dlaczego temperatura „zamrażała się” poza statusem?

Problem polegał na tym, że po wyjściu z zakładki Status moduł MCU pozostawał w trybie SLOW (pamięć NVRAM), ale przestawał być aktywnie odpytywany o nowe dane:

• System wyświetlał więc w pasku ostatnią odebraną wartość.
• Launcher z kolei „nie rozumiał” formatu danych SLOW dla prędkości, więc pokazywał 0 lub poprzednią wartość (freeze)

Dlaczego naprawa prędkości (NOP fix) naprawiła też temperaturę?

Naprawa polegała na zablokowaniu komendy 0x41, co wymusiło na MCU stałą pracę w trybie FAST (Raw CAN frames).
Można przypuszczać (na podstawie obserwacji i logiki działania aplikacji), że przyczyna naprawy temperatury jest następująca:

• Dostępność danych w trybie FAST: Choć tabela w źródłach sugeruje, że temperatura to domena trybu SLOW, w rzeczywistości surowe ramki CAN (tryb FAST) zawierają wszystkie informacje płynące z samochodu, w tym temperaturę.
• Ciągłość strumienia: W trybie FAST dane płyną gęsto (co ok. 400ms) i nie wymagają specjalnego odpytywania o nowe wartości.
• Parsowanie (dzielenie odebranego ciągu bitów lub bajtów na mniejsze części) przez CanAllInOne: Aplikacja CanAllInOne (która odpowiada za temperaturę w pasku) w trybie FAST najwyraźniej potrafi samodzielnie wyłuskać temperaturę z surowych ramek CAN. Dzięki temu, że MCU nie przełącza się już w tryb „odpytywania” (który po wyjściu ze Statusu zamierał), aplikacja ma stały dostęp do świeżych danych bezpośrednio z szyny CAN.