October 22 — Android Full-session development preview
OpenSAAB 0.1.1-preview.40 ARM64 is available. All four adapters — OBDLink MX+, Chipsoft Pro, Classic MDI and GM VCX Nano — retain their existing Full-session bindings. Normal connection entry no longer depends on a Read-only/Full picker or an inherited Read preference. Original confirmations, ECU authorization, cancellation and security-data integrity checks remain; there is no operator password.
On the exact signed APK with a 2004 Saab 9-3 Sport (9440), Chipsoft completed fresh security collection/import and showed service-reset completion; same-card readback matched the reset's oil-life/day values. Its ordinary DTC scan issued 20 requests across 19 module screens, stopping at the final LOCK checkpoint before the final CIM read. T8 Read Values received changing ECU traffic, and one warm reconnect obtained a fresh VIN without unplugging. MX+ separately reached original key-status and T8 Read Values screens.
Known issues remain: Chipsoft normal Stop reports protocol cleanup failure despite confirmed Android USB release. MX+ has intermittent socket connection failures and incomplete ordinary DTC scanning. An implausible airflow value and unnamed row need investigation; changing traffic does not validate numeric accuracy. Exact preview.40 MDI/Nano golden-path repeats are pending. These scoped results do not establish a stable release, complete vehicle coverage or full hardware-protection qualification.
The APK uses the previous public Android release's signing certificate. Stop diagnostics before updating, preserve important saved work and install over the existing app. Same-package reinstall preserved 675 exported evidence files; direct migration from preview.98 was not physically tested. Confirm OpenSAAB 0.1.1-preview.40 ARM64 after installation. If cleanup fails, retain the evidence and stop that workflow. Keep VINs, security data and raw recordings private.
October 20 — paired Intel and Apple-silicon Mac previews
OpenSAAB 0.2.28-mxplus.5 is available for Intel and Apple silicon. The security observer recognizes the active card's own TIS2000/RS232 transfer instructions. It includes the Dutch separator correction, preserves English recognition, and passed generated prompt checks from all ten catalog cards.
The native core now includes the app-owned OBDLink MX+ Bluetooth read-only preview alongside the existing USB backends. MX+ clearing, security collection/processing and programming are unavailable. MCP is off by default and requires explicit local enablement. No operator password is required; consent, cancellation and response/SSA integrity checks remain.
Both exact installed native Mac apps passed identity/hash/signature and software checks, all ten generated prompt cases, and Dutch firmware welcome/Main Menu/clean Stop through MCP. Fresh physical MX+/USB vehicle tests and a complete non-English collection → service → SSA-import workflow remain pending. Earlier Intel MX+ builds did read key status; those results do not qualify these new DMGs. Full platform parity remains unfinished, and this announcement does not release MX+ across every app version.
macOS 12+, ad-hoc signed and not notarized. Stop diagnostics and quit the old app before installing the fully versioned app alongside it. Mac updates are manual. Matching source, per-architecture manifests and native-component hash inventories accompany the release. Both Mac downloads and hashes → · Release notes and matching source →
October 16 — corrected Android and Mac previews
We caught an error while checking the previews and corrected it. Sorry for the confusion. Android 0.1.0-preview.98 and Mac 0.2.27-preview.3 for Apple silicon/Intel are available.
The operator password step is removed. The native/manual firmware wait now accepts a verified translated welcome without the false splash deadline. Consent, cancellation and response/SSA validation remain. The public primary-service compatibility header is not caller authentication.
Android passed exact signed-package emulator firmware/MCP/reporting/panic checks, retained-data installation and an exact-worker 160M German-welcome replay. Apple silicon passed 289 installed assertions and original Swedish148 offline navigation/Stop. Intel installed hashes, architecture and signatures pass; runtime remains pending. Physical Lenovo/adapter/vehicle and live security-service checks remain pending. Earlier live results retain their original build scope.
October 16 — current desktop previews and the next Android build
Intel Mac 0.2.26-intel-preview.7 is the latest public Intel download. It adds VCX Nano HS-CAN filtering, bounded key-status reads and a docked keypad. The exact installed package passed 299 app assertions and one 665-second live Nano session with original DTC/key-status screens and clean shutdown. Wider hardware, vehicle and macOS qualification remains pending. Apple silicon retains public 0.2.23-ui-parity.3; newer private M4 results are separate.
Windows 0.2.18-preview.5 is a separate experimental portable preview. It fixes translated Saab 148 welcome recognition and reopening fully cleared offline data, reports the packaged identity, and removes the operator password prompt. Exact-package offline checks passed in Windows 11 ARM / Fusion with x64 emulation. Physical adapter/vehicle tests and native Windows x64 remain pending; 0.2.17 retains its earlier recommendation.
Android remains on 0.1.0-preview.92. The Lenovo/Nano timeout candidate and removal of the extra operator password step are prepared in source for a future build. Software replay and isolated policy checks passed; a new product APK and Lenovo confirmation are still pending. Existing Android preview.92 and Intel preview.7 packages retain their password prompts. Consent and security-data validation remain part of processing.
October 16 — Android preview.92: reviewed panic locations
Android ARM64 0.1.0-preview.92 is available. Support reports now include a Rust panic’s source file, line, column and thread name. Panic headers are retained even after routine logs reach 2 MiB. Messages, raw bus traffic, build prefixes, VINs and security material remain excluded. Review, consent and explicit Send remain required.
The exact signed APK upgraded our Pixel 7, preserved firmware, saved reports and credentials, navigated the original offline firmware menus and stopped cleanly. Installed emulator checks covered a real Rust panic after 2 MiB, reporting, startup/password, security handoff and connection handling. Native executables are unchanged from preview.90. No physical adapter or vehicle tests were run on preview.92; these remain deferred.
Preview.92 ARM64 on Pixel 7, offline firmware navigation; no adapter or vehicle connection.
Preview.91 was kept private after a real panic exposed a newer Rust header format. Preview.92 handles it. This release improves failure evidence; it does not claim a fix for the crashes being reported. Desktop and ARM32 remain on their separate versions.
October 15 — Android preview.90 and the past 48 hours
Android ARM64 0.1.0-preview.90 is available. It restores the missing libtech2_recovered.so native binary from preview.89 (fixing offline emulation and recovered-core startup) and adds mandatory build-time SHA-256 verification, while retaining the recent Nano dual-bus startup and read-profile key-status handling, Chipsoft readiness/firmware guidance, Classic MDI USB sessions, authenticated MCP control, error evidence and security processing/import protections.
On the Pixel 7, recent development sessions reached original DTC lists, ignition-key status and Trionic 8 live values. Owner Chipsoft and Classic MDI tests on preview.87 also completed SPA Add. These results retain their own build scope: some Nano MCP tests used a debug preview.89 APK, saved reports can be partial, and exact signed preview.90 vehicle repeats remain pending. No Nano key programming or SPA write was performed during the recent MCP read test.
The signed preview.90 APK matches the versions installed on the Pixel and emulator. Live offline emulation and its startup/password and import/fallback rejection checks passed; the retained host Rust run passed 350 tests. The password gate does not itself establish ECU authorization.
Across platforms: the separate public Intel 0.2.26-intel-preview.3 tests diagnostic-language activation and deferred CANdi startup, retaining native MDI/Nano support. Apple-silicon CANdi, MCP and recovered-core experiments are separate development builds. Windows, ARM32 and iOS keep their own scope; full parity remains unfinished. The separate Mongoose Android 0.1.1-preview.3 remains a personal hardware-testing beta.
Research and stability: we reviewed 47 distinct Chipsoft-owned/starred repositories and implemented terminal Nano framing errors plus bounded Windows Chipsoft receive work in canonical source (231 host tests, seven target source checks). Release adoption and physical qualification remain tracked separately. Direct OTG has sometimes responded better than a hub; its cause is unconfirmed and controlled repeats are next.
Android ARM64 preview.70 brings together today’s Chipsoft, Nano and Classic MDI work. Fresh security collection offers manual or guided original menus; guided navigation waits for verified vehicle context. Nano can return to firmware after processing a cleanly stopped collection, and imported data replaces the old PRE-AUTH display. Reboot Nano is a separate adapter action.
Chipsoft detachment retains the interrupted-operation cause and last-screen evidence. MDI keeps diagnostics running when raw recording reaches its limit; truncation, real transport errors and cleanup remain distinct. Software regression and installed-package checks passed. Earlier vehicle observations are recorded separately, and the new fixes still need live repeats. Other platforms keep their own releases and qualification.
We tested Bluetooth engine reads, followed the original Tech 2 wake request, continued Nano initialization work and opened another testing route with a borrowed MDI.
These results cover particular adapters, builds and operations. A successful engine read does not establish a complete vehicle scan.
We also published Android ARM64 preview.45, Mac 0.2.22 and the Windows 0.2.17 portable preview, with matching source and checksums. The exact M4 Mac package completed EVO command-line VIN, ECM information and engine-code reads over BLE and Classic Bluetooth. Windows software checks passed in a VM without a Bluetooth radio; physical Windows Bluetooth and Intel Mac testing remain pending. The iOS source preview is published, while an installable iPhone package still needs signing and physical testing. Current downloads and test limits →
vLinker MC+ and Carista EVO: real engine reads
The Pixel 7 completed fresh VIN, seven Trionic 8 ECM identification reads and complete current/history engine-code reads over direct Bluetooth Classic with vLinker MC+. Repeated reads, reconnecting and reopening a saved report after restarting the app were checked. The installed preview.45 release APK returned zero ECM code records in this vehicle test; that result covers the engine report requested, not every module.
Carista EVO also completed VIN, seven ECM identifiers and a complete current/history engine-code report on Pixel 7 in the earlier preview.43 debug test. That report contained six records. The two results came from separate test contexts and are not a matched adapter comparison. No codes were cleared in either test.
Android and iOS simulator probes also returned matching engine information and code records against the bench through the Mac Bluetooth helper. Direct iPhone diagnostics remain unqualified.
The wake command: a specific remaining boundary
The original Tech 2 vehicle-check path requests a high-voltage single-wire CAN wake: a standard CAN data frame with ID 0x100 and zero data bytes. Preserving that exact request matters for the original firmware workflow.
We sent the tested empty direct-frame command to our vLinker MC+; its MIC3313 V2.0.92 firmware rejected it. The development bridge can now receive normal single-wire traffic and filtered high-speed traffic, and it reached the original DTC menu. It stopped when the firmware requested the unsupported wake, before sending guest vehicle-data commands. The actual high-voltage wake was not transmitted.
We still need a verified command sequence that sends that zero-byte data frame and restores normal transceiver mode. Substituting a remote frame, adding a filler byte or skipping the wake would change the request. Full original Tech 2 Bluetooth vehicle scans and body-module DTC reads remain incomplete.
EVO uses a related MIC controller, but its exact wake behavior remains untested. Shared command families do not establish identical capability. We have emailed vLinker support in Mandarin and Carista support in English for the supported wake commands and firmware requirements. The current findings do not establish that every firmware version is incapable of this operation.
VCX Nano: separate progress on startup
Our Windows direct USB/serial client has read a VIN matching the captured ECU response after normal original Tech2Win startup. Our sender uses its own commands without loading the vendor SDK, while the installed driver and prior vendor initialization remain prerequisites of that successful test.
The adapter-reboot command is also verified. Reboot and controlled full-power-loss tests exposed the remaining problem: direct channel opening fails before any VIN request. Original Tech2Win startup restores readiness; Manager's green-license screen and the tested DLL-load action did not replace it.
The next route is to capture initialization with Collector on the Windows EliteBook, qualify the Windows implementation, then carry the understood behavior into Android. Independent cold startup and full original-firmware diagnostics remain open gates.
MDI: another route to test
A borrowed MDI gives us hardware for the next comparison. The first offline Bosch MDI/MDI 2 and Nano driver comparison found common diagnostic API entry points and another lead into Nano startup. It does not establish common USB commands or a working OpenSAAB MDI backend.
We will establish the MDI's Windows vendor-driver baseline, record from before the first client opens, and compare channel setup and the same bounded VIN read. Wake, engine diagnostics and a body module need separate results. Each adapter will retain its own initialization and transport qualification.
Collector 0.5.5 is already published with the USB-hub adapter-selection fix. A fresh Windows 8 Pro 32-bit / MongoosePro GM II capture remains pending. Collector download and capture instructions →
Bluetooth candidates, Nano research and MDI testing are development work. Use the download page for published packages and their current support limits. Vehicle identifiers and raw captures stay private.
