Skip to content
View in the app

A better way to browse. Learn more.

Firmware, Software & Manuals for BYD Owners

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Vitaly

Administrators
  • Joined

  • Last visited

Everything posted by Vitaly

  1. An owner of BYD sub-brand Denza‘s Z9 GT revealed that the EV’s replacement battery costs only 78,700 yuan (~11,600 USD), after a collision necessitated replacing the Blade Battery 2.0 LFP pack. The quoted price was for a 122.5 kWh pack, available on top Z9 GT EV trims. The recently refreshed grand tourer is available in PHEV and EV trims, and retail pricing ranges from 269,800 to 369,800 yuan (39,600 to 54,300 USD). The maximum CLTC EV range is rated at 1036 km. The Z9 GT is compatible with BYD’s Flash Charging, which promises the following capabilities: 5 minutes from 10% to 70% 9 minutes from 10% to 97% Only 3 minutes slower at -30°C Posting on Weibo, the owner claimed that the quote was provided by a Denza dealership and did not include the cost of consumables or labour. The vehicle reportedly sustained undercarriage damage, affecting the Z9 GT’s battery. Market share of the top 10 EV battery makers in China, with BYD at No. 2. Source: China EV Datatracker BYD’s claimed pricing would equate to a per-kWh cost of 642 yuan, or 94 USD per kWh. Furthermore, the LFP pack’s quoted price means the battery accounts for 21% of the Z9 GT’s retail price. According to China EV Datatracker, BYD ranks second only to CATL in EV battery installations. As a result, the conglomerate would have an advantage in slashing battery costs for its own vehicles. A quote for replacing the Denza N7’s 91 kWh battery, including labour costs. Source: Weibo, Fei Zhai Kuai Le Tuan Tuan Zhang Although images of the Z9 GT’s battery quotation were not provided, a Denza N7 owner joined the discussion and shared their experience with EV battery replacement. Denza’s provided quote listed a price of 84290 yuan (~12,400 USD) for a 91 kWh LFP battery. For reference, the Denza N7 is a mid-size EV SUV that retails between 259,800 and 289,800 yuan (38,200 and 42,600 USD). The replacement battery, provided by Denza under warranty at no cost to the owner, accounts for 29% of the SUV’s retail price. It should be noted that the Denza N7 does not support Flash Charging, and no refresh has been announced for the model. The Z9 GT’s battery is one generation ahead of the N7’s, offering improved technology and a larger capacity. However, the claimed price for the Z9 GT’s larger, more advanced replacement battery pack is lower than the N7’s, despite its advancements. BYD’s domestic deliveries, May 2025 to April 2026. Source: China EV DataTracker This may be the result of BYD’s advancements in both battery manufacturing and cost control. China EV Datatracker shows that the conglomerate is experiencing a record 8-month sales slump in China, and better tech and lower prices may be the key to its reversal. Denza has also announced a European launch for the Z9 GT, with pre-sale pricing set at approximately 115,000 euros (130,000 USD). Furthermore, while replacement battery pricing will vary widely, it is expected that BYD will also leverage its cost advantages to usurp its legacy European rivals. Source: Weibo: Feng Mo Ge, Fei Zhai Kuai Le Tuan Tuan Zhang
  2. @tk dilan kumara Is the firmware installation stuck and the tablet is not working? Or was the update download stuck?
  3. BYD launched the third-generation Atto 3 electric crossover in China on May 21, where the model is sold domestically as the Yuan Plus. The updated EV arrived in four variants, priced from 119,900 yuan (16,600 USD) to 149,900 yuan (20,800 USD), and features BYD’s e-Platform 3.0 Evo architecture, second-generation Blade Battery technology, and flash charging. The new Atto 3 also introduces optional DiPilot 300 “God’s Eye B” driver assistance with lidar, while the top variant delivers up to 630 km CLTC range. Pricing and variants VariantCLTC rangePrice (yuan)Price (USD)540KM Leading540 km119,90016,600540KM Beyond540 km129,90018,000630KM Beyond630 km142,90019,800630KM Excellence630 km149,90020,800 Compiled by CarNewsChina Larger body and new exterior features The new-generation Atto 3 continues BYD’s “Dragon Face” styling language with a flatter front-end design, slim headlights, semi-hidden door handles, and a full-width rear light bar with woven-pattern lighting elements. The crossover measures 4,665 mm long, 1,895 mm wide, and 1,675 mm tall, riding on a 2,770 mm wheelbase. BYD also added a 180-litre powered front trunk with knock-to-open functionality. The rear cargo compartment offers up to 750 litres of storage volume. The model is available in nine exterior finishes, including dual-tone versions of Fantasy Pink, Trendy Blue, and Green. New Atto 3 is available in nine different colours. Credit: IT-home DiPilot 300 and upgraded cabin Higher trims can be equipped with BYD’s DiPilot 300 “God’s Eye B” advanced driver-assistance system featuring lidar and 30 sensing units. The system supports highway and urban navigation assist, as well as automated parking. Inside, the Atto 3 gains a larger floating central display running the latest DiLink system, a new two-spoke steering wheel, head-up display, column-mounted shifter, and 50W wireless phone charging. The crossover also adds a powered front passenger “Queen Seat” with leg support, a refrigerated storage box, ventilated and heated front seats, steering-wheel heating, and a 16-speaker sound system. Additional cabin storage includes a “figurine storage box” ahead of the front passenger seat, under-seat rear storage drawers, a glasses holder, and an integrated tissue-box compartment. Rear-wheel-drive platform The third-generation Atto 3 is built on BYD’s e-Platform 3.0 Evo and uses a rear-wheel-drive layout. Power comes from a rear-mounted electric motor producing either 200 kW or 240 kW. Battery options include 57.5 kWh and 68.5 kWh second-generation Blade Battery packs paired with BYD flash-charging technology. CLTC range is rated at 540 km or 630 km, depending on trim. The chassis adopts a front MacPherson and rear five-link independent suspension setup. BYD also equips the crossover with the DiSus-C intelligent damping body control system, iTAC 2.0 torque control, and TBC tyre blowout stability control. Earlier regulatory filings and showroom appearances had already revealed the Atto 3’s 240 kW rear-wheel-drive layout and flash-charging capability ahead of launch. China sales context Domestic sales of the BYD Atto 3, sold in China as the Yuan Plus, reached 5,111 units in April 2026, down 21.9% month-on-month and 58.4% year-on-year, according to China EV DataTracker data. March sales totalled 6,540 units, while February volume stood at 1,854 units. The model accounted for 3.4% of BYD brand sales in April. The Atto 3 was first launched in China in February 2022 as BYD’s first global e-Platform 3.0 SUV. According to Chinese media reports, cumulative global sales exceeded 1.1 million units across 116 countries and regions as of April 2026. The interior of the new BYD Atto 3 includes a larger touchscreen and a refrigerated storage compartment. Credit: Autohome
  4. DashCast v1.0.0DashCast v1.0.0 — Official Stable Release DashCast graduates from alpha and beta to its first official stable release. What's new Brand-new interface: the entire UI has been redesigned from scratch in Material 3, with a consistent navigation rail, modern bottom sheets, dialogs and tiles across all screens (Main, SysInfo, Diag, Log, Settings). Hardened projection lifecycle: the start/stop flow of cluster projection has been reinforced to prevent the edge-case bugs reported during beta (black card, stale surface, restart loops). Teardown and re-creation of the mirror surface are now synchronous and deterministic. Stability & cleanup: full lint + javac audit pass, dead code removed, thread-safety hardening (SimpleDateFormat in SysInfoActivity now uses ThreadLocal), 12 locales kept in sync. Community A dedicated Telegram channel has been created for support, feedback and discussion: https://t.me/+QPk_dmTVaNkxMjFk Documentation The documentation has been fully rewritten to match v1.0.0 and is available at: https://kiroha.github.io/byd-dashcast/ Install Download DashCast-v1.0.0-debug.apk below and install on a BYD DiLink 3.0 head unit (Android 10, platform-signed environment). LinksAPK download GitHub release page
  5. DashCast v0.9.94Audit cleanup pass 2 (post-0.9.93) Following the exhaustive read-only audit on the alpha/0.9 branch — incremental fixes, no regression. Improvements 🗑️ Dead code removed: orphan DashCastDaemon.java (~170 LoC, zero references, never invoked via app_process) ⚡ Perf: SysInfoActivity — 4× SimpleDateFormat allocations replaced by ThreadLocal cache (thread-safe) 🎨 Layouts: explicit paddingStart on activity_main / activity_sysinfo (RtlSymmetry fix) 🔒 EditText: importantForAutofill=no on log_filter + et_search_apps (debug fields) Metrics Lint: 75 → 71 issues Java code: −170 LoC Build: SUCCESSFUL, javac 0 warnings versionCode: 152 → 153 Intentionally not fixed 28 UseAppTint, 24 SmallSp, 8 ButtonStyle, 7 NestedWeights, 2 TooDeep/TooMany — UI design items, require on-device validation Branch: alpha/0.9 (no merge to main) APK: DashCast-v0.9.94-debug.apk (BYD platform signature) LinksAPK download GitHub release page
  6. @BydSy26pro Have you tried installing the app via a USB flash drive?
  7. A livestream test of BYD’s second-generation Blade Battery recorded a difference between localised temperature measurements and battery management system (BMS) readings during megawatt flash charging, alongside separate technical comments from BYD’s battery CTO regarding thermal design limits in high-temperature operation. The test, conducted under ambient conditions of approximately 25°C, recorded a peak localised external sensor temperature of 76.42°C at the centre-bottom area of the battery cell surface. During the same charging session, vehicle BMS data accessed via OBD reported a maximum pole temperature of 71°C. The difference between the two values reflects variation between localized measurement points and system-level temperature reporting within the battery management architecture. Livestream measurement structure According to the test data, multiple internal sensors within the pack recorded a maximum temperature spread of 6.5°C, ranging from 69.89°C to 76.42°C depending on sensor position. The readings indicate that temperature distribution within the battery pack was not uniform during sustained high-power charging conditions. Different sensor locations captured varying thermal states across the cell structure during the same charging cycle. In lithium iron phosphate (LFP) battery systems such as BYD’s Blade Battery architecture, heat generation during fast charging is typically concentrated near electrode interfaces and current collection paths, while dissipation depends on structural layout and cooling channel efficiency. Difference between BMS and localized measurement points The battery management system monitors pack conditions using distributed sensor inputs placed at selected points inside the battery pack. These readings are used for thermal control, safety management, and charging regulation. Localized external sensors or experimental measurement setups may capture temperature values at specific cell surface locations, which can reflect transient or peak thermal conditions not directly represented in system-level outputs. As a result, differences can appear between peak localized readings and BMS-reported values depending on sensor placement and sampling methodology. CTO technical comments on thermal limits In separate remarks published in a media interview, BYD battery CTO Sun Huajun addressed industry discussions around flash charging and thermal thresholds in next-generation battery systems. He stated that the commonly referenced 70°C level should not be treated as a fixed barrier in modern battery design, noting that thermal management capability has evolved alongside cell structure and electrochemical improvements. Sun also referenced BYD’s Blade Battery architecture, highlighting its structural layout and cooling design as key elements supporting high-power charging operation. He further discussed the company’s development approach combining production validation and long-cycle testing before commercialization. The CTO comments did not reference specific livestream measurements or sensor readings, but instead focused on system-level design principles and charging performance boundaries. Thermal behavior under megawatt charging conditions The recorded temperature range occurred during sustained high-power charging, where heat generation increases with current density across electrode interfaces. Under such conditions, transient temperature differences can form across different regions of the battery pack depending on internal resistance distribution, heat conduction pathways, and cooling system response speed. Even when system-level temperatures remain within operational control limits, localized variations can still occur across different measurement points within the pack. Measurement context and system-level interpretation Battery evaluation under fast-charging conditions typically combines embedded sensor data, thermal modeling, and post-test analysis to assess internal temperature distribution and control response. BMS readings represent system-level monitoring inputs rather than full spatial thermal mapping of all cell regions, which is typically reconstructed through modeling or additional instrumentation in testing environments. BYD’s EV battery installation in China. Credit: China EV DataTracker Industry context BYD’s lithium iron phosphate battery installations reached 10.49 GWh in April 2026, reflecting a 26% year-on-year decline, as the market continues to transition toward higher charging power and energy density requirements, according to China EV DataTracker.
  8. Мы собрали самые популярные автомобили Китая за апрель 2026 года в единый рейтинг, изучив статистику розничных продаж. Неожиданно лидером среди бензиновых машин стал Geely Coolray. Кроме того, марка Li Auto вернулась на высокое место в иерархии продаж. Апрель стал очередным переходным месяцем для китайской автомобильной промышленности, приходящей в себя после начавшегося в 2026 году кризиса. Продажи большей части брендов сейчас заметно ниже, чем в 2025-м. Впрочем, для некоторых участников рынка сложности стали возможностью для роста. Напомним, что мы анализируем статистику розничных продаж, которую составляет местная Ассоциация дилеров (CADA) при поддержке Ассоциации по информации о рынке легковых автомобилей (CPCA). Она использует как официальные данные производителей, так и сведения о регистрациях. Для начала разбираемся, как апрель закончили различные марки. Самые популярные бренды Китая в апреле 2026 годаПосле провальных результатов января и февраля марка BYD второй месяц подряд занимает первое место по объёму продаж на внутреннем рынке Китая с долей рынка в 10,5%. Впрочем, падение в сравнении с аналогичным периодом 2025-го всё ещё очень болезненное – 38,42%. Всего владельцами новых машин марки BYD в Китае стали 149,6 тысячи автомобилистов. Дилерский центр BYD в Китае / фото из соцсети Второе и третье места разделили Toyota и Volkswagen. Они реализовали 94,1 и 80 тысяч машин соответственно. Здесь стоит отметить, что впервые за долгое время в этом противостоянии стала лидировать японская компания. Обычно в Китае более высокие продажи демонстрирует именно Volkswagen. Дилерский центр Leapmotor в Китае / фото из соцсети Четвёртое место заняла марка Geely Galaxy, реализовавшая 62,9 тысячи машин. Она показала небольшое снижение в сравнении с аналогичным периодом прошлого года. На пятом месте неожиданно разместился входящий в состав концерна Stellantis китайский Leapmotor. Владельцами машин этого бренда стали 57,2 тысячи человек. Это на 102% больше прошлогоднего показателя. Дилерский центр Geely в Китае Шестое и седьмое место заняли традиционно присутствующие в топ-10 Geely и Wuling. Они реализовали 52,9 и 51,1 тысячи машин соответственно. Продажи обеих марок заметно сократились. Так, объём реализации Geely и вовсе упал на 47,3%. На восьмой строчке обосновалась Xiaomi, прибавившая примерно 28,3% с апреля прошлого года, реализовав 36,7 тысячи машин. Дилерский центр Li Auto в Китае / фото из соцсети На девятом месте оказалась Audi. А замкнул топ-10 выпадавший из элиты китайского рынка бренд Li Auto. Марке удалось реализовать 34,1 тысячи машин. Это пусть и незначительно, но лучше прошлогоднего показателя. Представители компании заявляли, что решили проблемы с производственными мощностями электрического кроссовера i6. Кроме того, в Li Auto надеются на рыночный успех гибридного L9 Livis. Ниже мы привели 20 самых популярных автомобильных брендов в Китае по итогам апреля 2026 года. МестоБрендОбъём продаж1BYD149 6062Toyota94 0813Volkswagen77 9954Geely Galaxy62 9335Leapmotor57 1616Wuling52 9297Geely51 0728Xiaomi36 7029Audi34 47110Li Auto34 08511HIMA32 75912BMW31 47113Changan30 68614Changan Nevo30 62115Chery30 52016Mercedes-Benz28 37617Deepal27 08218GAC Aion26 38319Nissan26 03620Tesla25 956Самые популярные автомобили Китая в апреле 2026 годаАктуальный для Китая Geely EX2 (Xingyuan) Самым популярным автомобилем Китая по итогам 2026 года стал хетчбэк Geely EX2. На внутреннем рынке эту модель знают как Geely Xingyuan. Такой исход вовсе не стал сюрпризом, ведь EX2 ранее уже был самой популярной моделью как 2025 года, так и первого квартала 2026-го. Владельцами EX2 стали 34,7 тысячи автомобилистов. Стоимость этого электрокара лежит в диапазоне 68,8–98,8 тысячи юаней (0,72–1,04 млн рублей). Новые седаны Xiaomi SU7 Второе место занял обновлённый седан Xiaomi SU7 с результатом продаж в 26,8 тысячи копий. Это неплохой результат для автомобиля с ценой 219,9–303,9 тысячи юаней (2,3–3,18 млн рублей рублей). Замкнул топ-3 традиционно пользующийся популярностью в КНР кроссовер Tesla Model Y. Его стоимость составляет 263,5–313,5 тысячи юаней (2,76–3,28 млн рублей). Кроссоверы Li Auto i6 и L6 А вот четвёртое место неожиданно занял кроссовер Li Auto i6. По итогам первого квартала эта модель занимала седьмое место. Но в компании решили проблемы с производственными мощностями этого SUV и готовы снова активно бороться за долю рынка и самые высокие позиции в рейтинге. Общие продажи i6 в апреле 2026 года составили 21 тысячу единиц. Цены этой модели лежат в пределах 249,8–269,8 тысячи юаней (2,6–2,82 млн рублей). Кроссовер BYD Yuan Up Пятёрку лучших закрыл кроссовер BYD Sealion 06. Следом за ним оказался Changan Nevo Q05. А седьмая строчка ушла ещё одному BYD. Им стал кроссовер Yuan Up, известный на некоторых рынках под именем Atto 2. Кроссовер Geely Coolray с атмосферным мотором в дилерском центре марки в Китае / фото из соцсети На восьмом месте неожиданно разместился Geely Coolray. Ранее эту модель можно было стабильно найти в районе 50-й позиции. Но теперь городской кроссовер попал в элиту китайского рынка с объёмом продаж 14,9 тысячи машин. Кроме того, он стал самым популярным бензиновым автомобилем апреля. Отметим, что в этой статистике учитываются рыночные результаты как версиис атмосферным мотором (Coolray Lite), так и с турбированным ДВС (Coolray L). Девятое и десятое места заняли Leapmotor B03X (A10) и BYD Dolphin. Ниже мы привели рейтинг 50 самых популярных автомобилей в Китае за апрель 2026 года. МестоМодельОбъём продаж1Geely EX234 7272Xiaomi SU726 8263Tesla Model Y22 9904Li Auto i621 0245BYD Sealion 0619 6496Changan Nevo Q0515 8147BYD Yuan Up15 6588Geely Coolray14 9239Leapmotor B03X14 37210BYD Dolphin14 21811Fang Cheng Bao Ti714 20112Deepal S0513 72213Xpeng Mona M0313 59514Wuling Hongguang Mini EV13 22915BYD Qin Plus13 22816MG 413 18917Nio ES813 02018BYD Song Pro12 54319Volkswagen Lavida12 45720Toyota Rav411 45221Geely Atlas11 31522Toyota Camry10 96323Toyota Frontlander10 87624Leapmotor C1010 72825Nissan Sylphy10 56426BYD Seal 0610 25427Haval Dargo10 22628BYD Qin L10 17129Toyota bZ3X10 02730Mercedes-Benz C-Class9 95031Xiaomi YU79 87632BYD Seagull9 86433Volkswagen Sagitar9 80634GAC Aion i609 71135Audi A6L9 44936Zeekr 9X9 31537Toyota Corolla Cross9 18438Changan CS35 Max9 14739Volkswagen Tiguan9 10940BMW 3 Series9 10741Geely Monjaro9 04642Changan CS75 Plus8 71643Aito M78 67044Chery QQ3 EV8 49445Mercedes-Benz GLC8 20045Volkswagen Passat8 12947Volkswagen Magotan8 12448Honda CR-V8 04249Leapmotor C117 93550ArcFox T17 589Денис БОБЫЛЕВ (YouTube)
  9. Chinese automaker BYD released new official images of the Seal 08 flagship sedan finished in a new “Liuguang Silver” exterior colour ahead of its expected second-quarter launch in China. The new sedan will become the flagship model of BYD’s Ocean series and one of the first large fastback sedans from the brand built on an 800V high-voltage platform. The latest images show the Seal 08 with a silver-grey paint finish developed using BASF clear coat technology. The model continues the design language previewed by the Ocean-S concept car, featuring slim wave-shaped daytime running lights, a closed front fascia, a fastback roofline, and a full-width rear light bar. Roof-mounted LiDAR is also visible, confirming the use of BYD’s “God’s Eye B” advanced driver assistance system. Seal 08 adopts fastback styling and full-width rear lighting design. Credit: Autohome Flagship Ocean sedan The Seal 08 measures 5150/1999/1505 mm with a 3030 mm wheelbase, positioning it in the large sedan segment. Inside, the car features BYD’s Ocean Aesthetics 2.0 cabin design, with a floating central display, a digital instrument cluster, a three-spoke steering wheel, and a wireless charging pad for front passengers. Earlier disclosures confirmed that the Seal 08 will be offered in both battery electric and plug-in hybrid variants. The pure electric version is built on an 800V architecture and uses BYD’s second-generation Blade Battery technology. BYD claims the EV version can achieve up to 900 km CLTC range and add 400 km of range after five minutes of charging. The dual-motor all-wheel-drive EV variant delivers a maximum output of 510 kW and accelerates from 0 to 100 km/h in 3.3 seconds. The car also adopts rear-wheel steering and the DiSus-A intelligent air suspension system. BYD Seal 08 interior features Ocean Aesthetics 2.0 flagship cabin layout. Plug-in hybrid version The Seal 08 DM-p plug-in hybrid was previously revealed with a 1.5T hybrid system paired with dual electric motors producing up to 400 kW combined output. It uses a 45.36 kWh LFP battery pack and was previously reported to have a WLTC pure-electric range of up to 300 km. BYD also stated the plug-in hybrid version can exceed 400 km CLTC electric range and deliver more than 1,000 km combined range. Previous previews also showed the Seal 08 adopting BYD’s latest flagship cockpit layout and megawatt flash-charging technology ahead of launch. BYD Seal 07 DM-i sales in China. Credit: China EV DataTracker Market context Domestic sales of the Seal 07 DM-i reached 628 units in April 2026, up 45.4% month-on-month but down 69.7% year-on-year, according to China EV DataTracker data. The model accounted for 0.4% of BYD brand sales during the month. The new Seal 08 will become one of BYD’s most technology-focused sedan offerings, combining 800V charging architecture, rear-wheel steering, air suspension, and dual powertrain options in a single platform.
  10. BYD is accelerating production expansion for its Blade Battery 2.0 packs after severe supply shortages disrupted deliveries of several flash-charge vehicle programs across its brands, including Fang Cheng Bao. Fang Cheng Bao, general manager of Xiong Tianbo, said on May 19 that deliveries of the Tai 3 flash-charge SUV lineup have now returned to normal levels after teams were dispatched to multiple manufacturing bases to increase output capacity. According to Xiong, staff were sent to production facilities in Shaanxi, Anhui, and Zhengzhou in recent weeks to support manufacturing operations and help resolve supply bottlenecks affecting flash-charge vehicle deliveries. Battery supply bottleneck The update follows BYD’s recent acknowledgement that production of Blade Battery 2.0 packs had fallen behind rapidly rising demand from its newest fast-charging EV models. Earlier reports said BYD was facing battery shortages amid surging orders for flash-charge vehicles across multiple sub-brands. The company’s latest battery system is being deployed in a growing number of vehicles equipped with ultra-fast charging technology. Pressure on battery supply became more visible after reports that launch timing for the BYD Great Tang SUV was delayed amid more than 100,000 pre-sale orders. The high order volume reportedly strained the allocation of Blade Battery 2.0 packs across BYD’s expanding model lineup. Xiong said all Tai 3 flash-charge variants are now entering regular delivery, including rear-wheel-drive, four-wheel-drive, and models equipped with the God’s Eye B driver-assistance system. More flash-charge models coming BYD is also preparing deliveries for several additional Fang Cheng Bao flash-charge models as battery output improves. According to Xiong, the Tai 7 EV flash-charge version has already begun shipping in some Chinese cities, with large-scale deliveries expected to begin in early June. Deliveries of the Bao 8 and Bao 5 flash-charge versions are expected to start in mid-June. She added that flash-charge vehicle allocation remains tight and said customers who finalise orders earlier are likely to receive vehicles sooner. On May 20, Fang Cheng Bao announced that cumulative sales had exceeded 400,000 vehicles. The company additionally said cumulative sales of the Tai 7 had surpassed 150,000 units. Earlier this month, Fang Cheng Bao launched the Bao 8 and Bao 5 flash-charge versions in China, with starting prices of 299,800 yuan (44,100 USD). Both models use BYD’s second-generation Blade Battery and flash-charging technology. The two SUVs also debuted the DiSus-P Ultra intelligent hydraulic body control system. According to Fang Cheng Bao, the system supports wheel-lift functionality across multiple driving conditions, including vehicle recovery, tyre replacement, and low-speed three-wheel driving. The company said the system offers up to 300 mm of wheel lift ground clearance and 200 mm of suspension height adjustment travel. The company has not disclosed its current Blade Battery 2.0 production capacity. Blade Battery teardown attention Battery supply discussions intensified this month after a third-party teardown of BYD’s latest Blade Battery pack circulated online. The teardown showed a 170-cell battery pack configuration and included a pack that had undergone a 40-hour freezing test before dismantling. The teardown team later defended the approximately eight-hour disassembly process following online criticism regarding teardown procedures. Fang Cheng Bao sales growth Fang Cheng Bao sold 21,138 vehicles in China in April 2026, according to China EV DataTracker data. The figure increased 110.6% year on year and was nearly unchanged from March’s 21,120 vehicles. The brand’s highest monthly sales volume to date occurred in December 2025, when deliveries reached 48,161 units.
  11. DashCast v0.9.0What's Changed since v0.8.7 This release starts a phased migration to Material Design 3, matching the target design in mockups/mockup_m3.html. The migration is split into 5 phases to detect any regression early. This release is Phase 1 only — foundation work. No layouts or business logic have been touched, so all existing features must keep working exactly as in v0.8.7. Phase 1 — Foundation Build & dependencies Bumped compileSdkVersion from 29 → 33 to enable Material 3 components. targetSdkVersion and minSdkVersion are still 29, so runtime behavior on the BYD Seal (Android 10 / DiLink 3.0) is unchanged. Added new dependency: com.google.android.material:material:1.9.0 (last version compatible with compileSdk 33). Theme Switched AppTheme parent from Theme.AppCompat.DayNight.DarkActionBar → Theme.Material3.DayNight.NoActionBar. The theme now exposes the full Material 3 color attribute set (colorPrimary, colorOnPrimary, colorPrimaryContainer, colorSurfaceVariant, colorOutline, etc.) so M3 components (MaterialButton, MaterialCardView, MaterialSwitch, …) introduced in later phases will automatically pick up the right palette. All legacy theme attributes (colorPrimaryDark, colorAccent, textColorPrimary, textColorSecondary, windowBackground) are still mapped to the original color resources, so existing layouts that reference them keep rendering as before. Color palette Added the full Material 3 token set to values/colors.xml (light scheme) and values-night/colors.xml (dark scheme): Primary / secondary / tertiary / error families Surface container levels (lowest → highest) Outline + outline variant Success and warning custom tokens Source color is #1565C0 (BYD blue), with the dark scheme tokens taken directly from mockup_m3.html so the rest of the migration can match the mockup pixel-for-pixel. All previously existing color names (bg_main, text_primary, text_secondary, bg_card, bg_dialog, colorPrimary, etc.) are preserved untouched so existing layouts continue to render identically. What is NOT in this release No layout file has been modified. No Java/Kotlin code has been modified. No feature, setting, dialog, navigation flow or business logic has been changed. No new Material 3 components have been introduced into screens yet — that work starts in Phase 2. Upcoming phases Phase 2 — Migrate common components (Button → MaterialButton, Switch/CheckBox → Material*, cards → MaterialCardView, FAB). Phase 3 — Migrate Welcome + Settings screens (navigation rail, top bar pattern). Phase 4 — Migrate Main + Diagnostics screens (most complex; keeps all cluster / ADB logic intact). Phase 5 — Migrate System Info + Log screens and list-item layouts. Full Changelog: v0.8.7...v0.9.0 LinksAPK download GitHub release page
  12. DashCast v0.8.7What's Changed since v0.8.6 UX Improvements Reconnect popup disabled by default — The "relaunch last app on cluster reconnect" popup is now opt-in (off by default) to avoid intrusive prompts for new users. Enable it in Settings if you want the behavior. Internationalization Added settings_reconnect_popup translation in all 12 supported locales: French, English, German, Spanish, Italian, Arabic, Belarusian, Kazakh, Russian, Turkish, Ukrainian, Uzbek. Corrected French wording for the reconnect popup setting. Previous (v0.8.6) Made the reconnect popup fully opt-in via a new checkbox in Settings (PREF_RECONNECT_POPUP). Fixed a race condition in FloatingRemoteButton where show() was silently lost when called before the overlay was ready — added sShouldBeVisible static flag with deferred visibility after createOverlay() and onStart() re-sync. Full Changelog: v0.8.6...v0.8.7 LinksAPK download GitHub release page
  13. DashCast v0.8.6DashCast v0.8.6 — Floating button reliability fix Branch: alpha/0.7 — not merged to main Build: 117 · platform-signed · API 29 Bug Fix FloatingRemoteButton race condition (cc939a3) The floating 📺 mirror button and the in-app "Show Mirror" button were intermittently invisible after launching an app on the cluster then hiding the mirror view. The behavior was non-deterministic ("random") because it depended on service startup timing. Root cause: FloatingRemoteButton.show() was silently discarded when called before the overlay was ready. Two async gaps caused this: Service startup race — startService() is asynchronous; sInstance and mFloatView are null until onStartCommand() + createOverlay() complete. Any show() call during this window was lost. Overlay permission grant race — On first install, SYSTEM_ALERT_WINDOW is auto-granted via ADB shell (async). During the grant round-trip, mFloatView remains null and the overlay is created with View.GONE. Nobody re-called show() after creation succeeded. Fix applied: File Change FloatingRemoteButton.java Added static volatile boolean sShouldBeVisible flag. show()/hide() now persist the desired state before attempting the view operation. After createOverlay() succeeds, the flag is read and the button is made visible immediately if an app is active. MainActivity.java In onStart(), explicitly re-sync btnShowMirror visibility + call FloatingRemoteButton.show() whenever mCurrentDashboardApp != null and the service is already bound. Covers the stop/start lifecycle where updateDashboardStatus() is not re-invoked. Impact: Both the floating overlay button and the top-bar "Show Mirror" button now appear reliably regardless of service/Activity lifecycle ordering. Upgrade notes Direct install over v0.8.5 — no data loss, no uninstall needed versionCode incremented (116 → 117) LinksAPK download GitHub release page
  14. DashCast v0.8.5What's changed since v0.8.2 This release replaces the broken getTasks() state poller, removes a dangerous diagnostic button that could brick the cluster until reboot, and applies a full multi-axis audit pass (HIGH → LOW). Display-state poller — getTasks() → pidof (v0.8.3) Problem: The log-only poller from v0.8.2 confirmed what the symptoms had suggested: IActivityTaskManager.getTasks() on DiLink 3.0 does not report tasks running on the cluster VirtualDisplay. Tasks on the main display were visible, tasks on display 1 (Fission) were never returned. This made the original mutating reconciliation logic — disabled in v0.8.2 — fundamentally unfixable: there is no way to ask the ATM for the cluster app's running state. Fix: reconcileDisplayState() no longer uses getTasks() at all. It now runs a pidof <package> over the existing ADB localhost relay (uid 2000), which can read /proc despite hidepid=2. A single async call every 5 s, with the active package captured by reference; logs the PID when alive, clears cluster state and stops the mirror when the process is gone. The previous ~80 lines of IActivityTaskManager reflection were removed. The state poll is started/stopped together with the screenshot loop, so it only runs while MainActivity is in the foreground. Diagnostic safety — OSD On/Off buttons removed (v0.8.3) Problem: Testing the experimental btnFissionOsdOff button in DiagActivity revealed it sends sendInfo(1000, 20), which disables the entire cluster display on the BYD Seal EU. Once triggered, the cluster cannot be re-enabled by the app: a hardware reboot via long-press of the volume button is required. Fix: Both btnFissionOsdOff and btnFissionOsdOn and their handlers have been removed from DiagActivity, along with the four related strings (diag_btn_fission_osd_off/on, diag_fission_osd_off_sent/on_sent) and the corresponding Button widgets in activity_diag.xml. The section description was shortened to reflect the reduced set of controls. Diagnostic correctness — overscan read fixed (v0.8.3) Problem: DiagActivity attempted to read the current overscan via wm overscan -d 1 to confirm the value applied by the settings screen. On API 29, wm overscan is write-only: it accepts coordinates but returns an empty body. The diag screen always reported "overscan = 0,0,0,0", masking the real persisted value. Fix: The verify step now runs dumpsys display | grep -i overscan instead, which exposes the SurfaceFlinger-side display overscan rect actually in effect. Multi-axis audit (HIGH findings, v0.8.3) MainActivity.reconcileDisplayState — use-after-destroy in the pidof callback. The async pidof callback was posting a Runnable to runOnUiThread that re-checked package equality and then mutated UI fields. Between the bg-thread pidof completion and the Runnable running on the main thread, onDestroy could fire and null out the views referenced by clearClusterState()/stopClusterMirror(). Now the Runnable first checks isFinishing() || isDestroyed() and returns early. ClusterService.findRunningTaskId — NPE on getRunningTasks(). am.getRunningTasks(50) is documented to return a non-null list, but on rare framework error paths it can return null (observed historically on third-party Android forks). The helper now null-checks the return value and returns -1 instead of dereferencing a null List. Multi-axis audit (MEDIUM findings, v0.8.4) ClusterService — move-task-thread post-destroy guard. The unnamed background thread spawned by moveTaskToDisplay() posts its result back to mMainHandler. Between onDestroy (which already drains the handler with removeCallbacksAndMessages(null)) and the bg thread posting the next Runnable, there is a small window where a posted callback may execute after the service is dead and reach mLauncher/mMirrorManager (both freed). A new volatile boolean mDestroyed is now set in onDestroy(), and every post-callback in the move-task-thread path (success branch + fallbackLaunch posted runnable) returns early when the flag is set. MainActivity.onDestroy — mMirrorSurface not released. The Surface wrapping the TextureView's SurfaceTexture was retained until GC after the Activity was destroyed. onDestroy now explicitly mMirrorSurface.release() and nulls the field, guarded by a try/catch (Exception ignored) for the case where the underlying texture was already torn down. AdbLocalClient.sendInfo — incomplete shell argument escaping. The s16 argument to service call AutoContainer 2 ... s16 "<infoStr>" previously escaped only ". If an infoStr ever contained $ (variable/arithmetic expansion) or ` (command substitution), the shell would interpret it before reaching AutoContainer. Escaping order is now: \\ first (avoids double-escaping the backslashes we are about to insert), then ", $, `. No current call site uses untrusted input here, but the function is on a public ADB-relay path and the fix is preventive. Multi-axis audit (LOW findings, v0.8.5) UpdateChecker.downloadToFile — HTTPS→HTTP redirect downgrade. The manual 5-step redirect follower accepted any Location header, including http://.... A misconfigured GitHub CDN response or a hostile MITM could downgrade the APK download to plaintext. The platform-signed APK would still be rejected by PackageInstaller on signature mismatch, but the new check fails fast with "Insecure redirect target: ..." if the redirect target is not https:// (case-insensitive, Locale.ROOT). MainActivity.startScreenshotLoop — Activity reference held by ADB executor queue. The screenshot loop passed MainActivity.this as the Context argument to AdbLocalClient.captureClusterDisplay. While a capture was in flight, the static sExecutor's task queue held a strong reference to the Activity. After verifying that captureClusterDisplay only uses the context for connect(), getExternalCacheDir() and getCacheDir() — all valid on applicationContext — the call site now passes getApplicationContext(). The bitmap is still delivered on the Activity via runOnUiThread inside the BitmapCallback, so the UI path is unchanged. Verified clean (no fix applied) The audit also confirmed: All Parcel.obtain() / MotionEvent.obtain() are recycled in finally All InputStream / Reader / Writer / Socket use try-with-resources Single ad-hoc ExecutorService (in SysInfoActivity) calls shutdown() after submit registerReceiver ↔ unregisterReceiver paired in MainActivity bindService ↔ unbindService paired in MainActivity.onDestroy VirtualDisplay.release() in finally in DashCastDaemon SurfaceFlinger display token released in MirrorDaemon.stopMirror() All SharedPreferences writes use apply(), never commit() PendingIntent.FLAG_IMMUTABLE used everywhere except UpdateChecker where mutability is documented to be required by PackageInstaller TLS via system TrustManager (no custom verifier, no insecure Random) No exported component without a system-protected action or a signature-level guard No secrets/PII logged Branch: alpha/0.7 — not merged to main APK: debug build, signed with the BYD platform keystore Compatibility: BYD Seal EU (DiLink 3.0, API 29), 1920×720 cluster VirtualDisplay owned by com.xdja.containerservice LinksAPK download GitHub release page
  15. DashCast v0.8.2What's changed since v0.8.1 fix: convert display-state poller to log-only mode (d863984) Problem: The 5-second IActivityTaskManager.getTasks() poller introduced in v0.8.1 was incorrectly clearing cluster state (mirror view + app icons) every time it ran. When a user launched an app on the cluster, the mirror would appear but then get killed ~5 seconds later by reconcileDisplayState(), resetting the UI as if no app was running. Root cause: getTasks() on DiLink 3.0 most likely does not return tasks running on the VirtualDisplay (Fission display). The poller interpreted the missing task as "app is dead" and called clearClusterState(), which: Cleared mCurrentDashboardPkg / mCurrentDashboardApp Removed shared prefs Reset the adapter (no active icon, no red kill cross) Called showAppList() — hiding the mirror view Fix: reconcileDisplayState() now operates in log-only mode: Still polls getTasks() every 5 seconds while the Activity is visible Logs ALL tasks with baseActivity, topActivity, and displayId for each entry Logs a summary showing whether the tracked cluster/main packages were found and on which display Does NOT mutate any state — no clearClusterState(), no setMainPackage(), no shared prefs writes Bonus improvements in the logger: Also checks topActivity field as fallback when baseActivity is null Logs when getTasks() returns null or empty (was silently returning before) Full task dump enables post-test analysis of what the DiLink ROM actually reports The reconciliation logic will be re-enabled once we confirm getTasks() behavior on the BYD head unit via these diagnostic logs. Branch: alpha/0.7 — not merged to main LinksAPK download GitHub release page
  16. Vitaly posted a topic in Applications
    Open BYD The app uses ADB and lets you remap steering wheel buttons to control car functions like AC or windows, launch apps automatically, use split-screen, and cast apps to the dashboard or move them back to the main screen. In version 5.1 there was a mini mode (just a small window on the right) of the dashboard that the app supports, allowing you to save custom offsets and resize of the projection while in that mode. It works well on DiLink 5.1. There’s partial compatibility with DiLink 5, where some features like split-screen or car controls may not work depending on the version. On DiLink 6, BYD locked down several of these features (casting to the dashboard, split-screen). OpenBYD 1.0.apk
  17. As the new energy vehicle (NEV) market penetration surpasses 60%, the battle for dominance has shifted toward battery performance. At the centre of this shift is BYD’s second-generation Blade Battery and its “Flash Charge” technology. In a recent in-depth interview with 36kr Auto, Sun Huajun, CTO of BYD’s battery division, addressed industry scepticism and outlined the company’s vision for the future of Lithium Iron Phosphate (LFP) technology. Breaking the 9-minute barrier BYD’s second-generation Blade Battery introduces staggering performance metrics. Utilising a massive 1500kW charging pile, the battery can charge from 10% to 97% in nine minutes. Even in extreme cold conditions of -30°C, the charge from 20% to 97% takes only three minutes longer than at room temperature. To support this technology, BYD has launched the “Flash Charge China” strategy, aiming to establish 20,000 flash-charging stations across the country by the end of this year. As of May 6, the company has already completed 5,924 stations. Sun Huajun, CEO of BYD Battery division. Credit: Sohu Addressing heat and safety concerns The rapid charging speed has sparked debate among industry experts, with some arguing that such high power inevitably generates excessive heat, potentially exceeding the 65°C to 70°C safety threshold for battery materials. Critics worry that high temperatures could damage the SEI film (Solid Electrolyte Interphase), compromising battery life and safety. Sun Huajun dismissed these concerns as being based on “outdated experience.” He noted that every leap in charging speed – from 1C to 5C- was initially met with claims that it would “hurt the battery.” “70°C was simply the cognitive boundary of the past,” Sun stated. He explained that the Blade Battery’s symmetrical structure and dual-surface cooling provide a natural advantage for heat management. BYD has optimised the battery dimensions to reduce internal resistance and ensure uniform temperature distribution. According to Sun, the company conducted over 1,000 full flash-charge cycles and simulated extreme long-distance trips – such as driving from Hainan to Harbin – to verify reliability before mass production. The “high-end” debate Sun also responded sharply to claims from CATL that using LFP batteries in vehicles priced above 250,000 yuan (36,800 USD) constitutes a “downgrade.” He pointed to the Yangwang U9, a high-performance supercar priced at over 10,000,000 yuan (1,470,600 USD), which utilises LFP technology to achieve elite acceleration and handling. “Who defines what is ‘high-end’?” Sun questioned. “Is it a battery supplier drawing a line based on energy density, or is it the consumer based on handling, comfort, charging speed, and long-term safety? If a supplier defines high-end, it respects neither the automaker’s engineering nor the user’s judgment.” He reiterated BYD’s philosophy: “Safety is the ultimate luxury.” Future outlook and strategy While acknowledging the current energy density of LFP systems – roughly 130 to 140 Wh/kg – Sun expressed confidence that there is still significant room for growth. BYD continues to explore multiple paths, including sodium-ion, solid-state, and “lithium-free” anode technologies, to deepen its understanding of electrochemistry. Sun believes that flash-charging technology will raise the barrier to entry for the industry. “Anyone can do 1C or 2C charging,” he said. “But doing it in under ten minutes requires deep electrochemical research and systemic engineering that not everyone can achieve in the short term.”
  18. BYD SDK 🇺🇸 English The BYD SDK is a development toolkit and API platform for creating custom applications and integrations for BYD vehicles. It enables developers to access vehicle data, interact with the infotainment system, navigation, climate control, battery and charging information, and other smart vehicle features. The SDK is designed for Android-based in-car applications, monitoring tools, multimedia services, and third-party ecosystem integrations within the BYD platform. 🇷🇺 Russian SDK для автомобилей BYD — это набор инструментов и API для разработки собственных приложений и интеграций с мультимедийной системой автомобиля. Платформа позволяет получать данные автомобиля, работать с функциями мультимедиа, навигацией, климат-контролем, состоянием батареи, зарядкой и другими возможностями интеллектуального автомобиля. SDK предназначен для создания Android-приложений, сервисов мониторинга, мультимедиа-решений и интеграции сторонних сервисов в экосистему BYD. Version Download v1.0.5 sdk_v1.0.5.zip
  19. DashCast v0.8.1What's changed since v0.8.0 feat: activity task manager polling (bb7bb0c) MainActivity — replaced trust-only-our-bookkeeping approach with a 5-second poll of IActivityTaskManager.getTasks() while the activity is visible. Detects three edge cases the previous logic missed: App crashed or OOM-killed → task gone → stale cluster/main state is cleared App moved to display 0 externally → reclassified as main-display Main-display app moved to cluster externally → promoted to cluster state Uses the same displayId reflection pattern already proven in DiagActivity. Poll runs in onStart() / onStop() — zero background cost. Extracted clearClusterState() helper shared with the reconciliation path. fix: eager cluster state clear before async kill/restore (f6a50cf) MainActivity — prevents a race condition where the 5-second display-state poll could fire between moveTaskToDisplay(pkg, 0) and forceStopApp(), incorrectly setting mMainDisplayPkg. Three paths fixed: doKillApp, restoreBydDashboard, originCluster. The captured package is still forwarded to restoreBydOnCluster / restoreOriginCluster for the force-stop before sendInfo(18). feat: cluster surface diagnostics buttons (e1cd30b) DiagActivity — new button row in the Fission Pipeline section to investigate the partial-surface projection issue (native Qt HUD overlays remaining visible above/below the VirtualDisplay): Button Command Purpose 🔍 Measure surface DisplayManager + wm size/overscan -d X + dumpsys display Read actual VirtualDisplay dimensions OSD Off sendInfo(1000, 20) Attempt to hide Qt native HUD overlays (speed / gear / battery) OSD On sendInfo(1000, 19) Re-enable Qt native HUD overlays Overscan 0,0,0,0 wm overscan 0,0,0,0 -d X Remove artificial margins on the Fission display Branch: alpha/0.7 — not merged to main LinksAPK download GitHub release page
  20. DashCast v0.8.0DashCast 0.8.0 — Pre-release Stabilization release closing the alpha/0.7 development line. Eighteen consecutive sanity passes (P0 → P16) hardened lifecycle, concurrency and native resource handling across the entire application and the system-level MirrorDaemon (uid=2000). No new user-facing features; no API-level bump; target remains Android API 29 (DiLink 3). Pre-release: not merged to main, remains on branch alpha/0.7. Baseline: v0.7.9-alpha → v0.8.0 · 17 commits · versionCode 96 → 111 Highlights Cluster mirror reliability: no more orphan SurfaceControl display tokens on daemon setup failure; Surface/SurfaceTexture lifecycle now mirrors the size-changed/destroyed contract end-to-end. Concurrency hygiene: every long-lived background thread is now named for tombstone/anr triage; activity-scoped executors use named daemon ThreadFactory; volatile mDestroyed flag added to every Activity that posts back to UI from a worker. No more ANR-risk paths in onCreate: boot-time cleanup of cluster display affinity is now off-loaded to a daemon thread. Native resource leaks closed: 5 × Parcel.obtain, 3 × MotionEvent.obtain, 1 × InputStream and the setupMirror token are all released on every exit path (success, exception, lifecycle end). Dead code removed: 4+ unused methods, 1 orphan BroadcastReceiver, the entire profile-feature placeholder UI, redundant Handler/StringBuilder instances. Resource lifecycle & native handles MirrorDaemon.setupMirror — when createDisplay succeeds but a later SurfaceControl.Transaction reflection step throws, the catch path now calls stopMirror() (which captures the token, nulls the static, then invokes destroyDisplay) instead of merely clearing the reference. The SurfaceFlinger display token is no longer leaked for the lifetime of the daemon process. (P16) ClusterInputForwarder.injectTouchAtMulti — MotionEvent and Parcel are recycled inside a finally on both daemon and non-daemon paths, even when InputManager.injectInputEvent() / Binder.transact() throws. (P9, P10) ClusterInputForwarder.injectKey — Parcel is recycled per iteration inside the daemon for-loop. (P9) MirrorDaemon.readParcelable(MotionEvent) — recycled in finally. (P11) ClusterMirrorManager.stopMirrorViaDaemon — Parcel recycled in finally, symmetric with startMirrorViaDaemon. (P9) UpdateChecker.httpGet — InputStream closed via try-with-resources. (P10) Concurrency & lifecycle safety MainActivity.onCreate — cleanupDisplayAffinityAtBoot() (which performs N IActivityTaskManager binder calls via reflection) is now off-loaded to a daemon thread boot-cleanup-fallback using getApplicationContext() to avoid Activity retention. Eliminates a latent ANR risk when the persisted cluster-package set is non-trivial. (P15) MainActivity.onDestroy — screenshot handler lambdas are now cancelled via removeCallbacksAndMessages(null); the screenshot-loop TOCTOU race against mScreenshotRunnable is closed. (P1, P12) AdbLocalClient.sExecutor — now uses a named daemon ThreadFactory (adb-local-N). (P13) MainActivity.loadAppsAsync — executor uses a named daemon ThreadFactory (load-apps). (P14) MirrorDaemon.injectMotion (daemon path) — MotionEvent is recycled in finally. (P11) BootReceiver — wrapped in goAsync() + result.finish() to prevent the background reflection thread from being killed mid-execution by the system. (P1) DiagActivity / SettingsActivity / SysInfoActivity — every one of the ~70 runOnUiThread posts is now guarded by a volatile mDestroyed flag, with a safeRunOnUiThread() helper for the diag screen. (P2, P4) SysInfoActivity.publishUpdate — the worker-side mDestroyed check before runOnUiThread is now duplicated inside the main-thread Runnable (the original check was racy against onDestroy between queueing and dispatch). (P16) FloatingRemoteButton.createOverlay — removed redundant local Handler, reuses mDimHandler. (P9) ClusterMirrorManager.unlockHiddenApis — guarded by AtomicBoolean; the VMRuntime.setHiddenApiExemptions reflection chain is no longer re-run on every Activity recreation. (P2) Correctness fixes AdbLocalClient.startMirrorDaemon — safeOut() was converting empty strings to "(empty)", causing the post-launch ps -A verification to always succeed and masking real daemon-start failures. Replaced with direct getAllOutput().trim(). (P5) MainActivity.moveTaskToDisplayZero — now returns true when the task is not found (the goal is "task absent from display 1", not "task moved"). (P1) DiagActivity.runAdas — fixed argument inversion bug. (P8) LocaleHelper — applyLocale() and saveLanguage() separated; attachBaseContext no longer writes to SharedPreferences on every Activity creation. (P1) Robustness & defensive guards AppCompat AlertDialog from a Service — FloatingRemoteButton now uses WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY for its in-service dialogs (a non-Activity context cannot host a default AlertDialog window). (P7) PendingIntent flags — FLAG_IMMUTABLE everywhere except UpdateChecker.installApk where FLAG_UPDATE_CURRENT (without IMMUTABLE) is required by PackageInstaller to inject extras (documented inline). (P7) Foreground services — both ClusterService and FloatingRemoteButton call startForeground() within the 5-second window and provide setSmallIcon(). Performance AppListAdapter — per-bind new ColorDrawable() allocations replaced with reusable ConstantState instances (CS_FG_ACTIVE, CS_FG_ON_MAIN). (P4) LogActivity — adaptive polling switched from a fixed 500 ms cadence to 500 ms when entries change / 2000 ms when idle, then short-circuits the whole rebuild when neither the entry count nor the filter changed. (P1, P7) Cleanup & dead code removal AdbLocalClient — removed scanSniffer(), killSniffer(), checkTaskBoundsOnDisplay() (no callers), SNIFFER_KILL_CMD constant. (P2, P8) AppLogger — removed shareTextAsFile() (no callers). (P3) MainActivity — removed dead mShowMirrorReceiver BroadcastReceiver (FloatingRemoteButton uses startActivity, not sendBroadcast). (P3) ClusterMirrorManager.startMirror — unused Context parameter removed. (P3) ClusterInputForwarder — dead forwardTouchFinal() removed (only multi-pointer path is used). (P1) AppShortcut — unused intent field and constructor parameter removed. (P1) SysInfoActivity — redundant StringBuilder re-init before executor.submit() removed. (P1) LogActivity — removed dead TAG constant. (P8) Profile feature — placeholder UI removed entirely: spinner (MainActivity), section (SettingsActivity), layout blocks (activity_main.xml, activity_settings.xml), profile strings in all 12 locale files. (P2) Code quality Pref-key constants — every literal "byd_app_prefs", "recent_cluster_apps", "boot_auto_start_enabled", "show_category_filters", "visual_overscan_mode" etc. centralized as SettingsActivity.PREF_* constants and referenced from MainActivity, BootReceiver, FloatingRemoteButton. (P4, P5, P6) AppListAdapter — magic colors 0x1A4CAF50 / 0x141565C0 extracted as COLOR_FG_ACTIVE / COLOR_FG_ON_MAIN named constants. (P2) Misleading Javadoc — FloatingRemoteButton comment corrected (uses startActivity, not broadcast). (P3) Compatibility Target SDK / min SDK: unchanged (API 29 / DiLink 3, BYD Seal EU) App signature: unchanged (platform-signed) Permissions: unchanged Cluster display id: still hardcoded to 1 (intentional, DiLink 3 constant) Verification 5-axis static audit completed (concurrence / resources / Android-API29 / security / correctness) All 17 commits build green (./gradlew assembleDebug) No API 30+ symbol introduced No new dependency added Known limitations carried over from 0.7.x DiagActivity contains 12 anonymous new Thread(() -> ...) lambdas — kept as-is (internal diagnostic tool, short-lived tasks) UpdateChecker.installApk PendingIntent deliberately mutable (PackageInstaller contract) wm overscan ... -d 1 hardcoded for DiLink 3 cluster display Artifacts DashCast-v0.8.0-debug.apk — platform-signed debug build, installable on BYD Seal EU DiLink 3 head units. Branch policy This pre-release stays on alpha/0.7. No merge to main yet. Promotion to a stable 0.8.x line is gated on device-side validation. LinksAPK download GitHub release page
  21. DashCast v0.6.8-betaWhat's changed — v0.6.0 → v0.6.8 v0.6.1 — i18n cleanup Purged 400+ unused translation keys across all 12 locales Fixed hardcoded strings that were bypassing the translation system v0.6.2 — Bug fixes & performance Fix ghost-restore bug: PREF_CLUSTER_PKG/PREF_CLUSTER_NAME now correctly cleared on force-stop, preventing a killed app from reappearing on the cluster after Activity recreation Dead code removal: collapsed duplicate isFavorite branches in AppListAdapter i18n: extracted 5 new keys (OTA dialog buttons, overflow menu labels) to all 12 locales Performance: reduced SharedPreferences open calls from 3 → 1 in ClusterService inset getters v0.6.3 — Sanity QoL #2 Extracted all hardcoded French notification strings (FloatingLogButton, FloatingRemoteButton, SysInfoActivity) to R.string across all 12 locales 5 new string keys added v0.6.4 — Fix ANR risk findRunningTaskId() (calls ActivityManager.getRunningTasks()) moved off the main thread to a dedicated background thread, eliminating an ANR risk in the resize button handler v0.6.5 — UX improvements Status dot (grey/yellow/green) alongside cluster status text Real-time search bar to filter the installed app list List/Grid toggle button relocated to the title header (always visible) Cluster panel collapse strip (▼/▲) to go full-screen while keeping the mirror Inset overlay preview: orange bands show resize margins during adjustment One-shot first-launch tooltip: tap any app to send it to the cluster 3 new string keys across all 12 locales v0.6.6 — Robustness & polish 30-second activation timeout: re-enables the button and shows a toast if the cluster never responds Kill confirmation dialog: AlertDialog before force-stopping any app (avoids accidental taps) Relaunch button (↺) in the control panel header: force-stops then relaunches the current app OTA changelog now rendered as styled Markdown (## headings, bullet lists, bold) 150 ms fade animation on list ↔ mirror transitions Active row background tint (green/blue semi-transparent) on currently active items Reconnect reminder: after manual re-activation, offers to relaunch the last cluster app 8 new string keys across all 12 locales (179 keys total per locale) v0.6.7 — Auto-apply saved insets Per-app insets (wm overscan + resizeActiveTask) are automatically applied 500 ms after a successful cluster launch if custom values were previously saved for that package Guard: cancelled if the active cluster app changes during the delay No manual Apply tap required v0.6.8 — Fix recents cleanup after kill Fixed silent failure of task ID extraction on Android 10 / DiLink 3.0: grep -o '#[0-9]\+' unsupported by Android busybox → replaced with portable sed BRE Wrong ID extracted (recents index instead of TaskRecord ID) → new sed expression targets only the TaskRecord entry am task rm does not exist on Android 10 → replaced with am task remove + app_process64/32-bit fallback via TaskRemover reflection helper Added [DashCast-recents] log line in LogActivity for on-device verification of extracted task IDs LinksAPK download GitHub release page
  22. DashCast 0.5.1Comprehensive i18n support localized hardcoded strings across UI, overscan layouts, and system Toasts in all 12 supported languages. Fixed missing 'Adjust' button from the manual UI diagram. LinksAPK download GitHub release page
  23. DashCast v0.5.0-betaSecond Beta Release! Merged all 0.4.x refactorings (UI revamp, app-specific Overscan memory saving and injection, intent fixes, native reflection code). LinksAPK download GitHub release page
  24. DashCast v0.2.1Version 0.2.1 🛠️ Bug Fixes & Stability Resources: Safely closed the BufferedReader stream in MirrorDaemon.java using a try-with-resources block to prevent memory leaks (orphaned streams from dumpsys). Broadcaster Permissions: Applied the UnspecifiedImmutableFlag to UpdateChecker.java to resolve intent false positives during the silent OTA update process. Manifest compliance: Explicitly added the android:exported="true" attribute to the main entry point, as required for Android 12+. UI Memory Leaks: Added the @SuppressLint("StaticFieldLeak") annotation to FloatingRemoteButton.java to suppress warnings regarding its managed, bound lifecycle. 🧹 Optimizations Orphaned Strings Cleanup: Removed unused string resources (such as menu_settings) across all localizations and dictionaries, reducing the APK build size. Storage Management: Identified and cleared old, invalid PackageInstaller sessions that were consuming massive amounts of persistent cache storage (~800 MB from previous development builds). LinksAPK download GitHub release page
  25. DashCast v0.2.0-betaFirst beta release What's new OTA updates: DashCast now updates itself automatically from GitHub Releases Download progress bar Install via PackageInstaller with system confirmation prompt Pre-release toggle in Settings to receive alpha builds Package rename: com.byd.myapp → com.byd.dashcast Bug fixes Removed broken watchdog (false positives on DiLink 3.0) Fix OTA: removed FLAG_IMMUTABLE from PendingIntent → PackageInstaller result now received correctly Fix blocking update dialog → dismissed automatically when install starts LinksAPK download GitHub release page

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.