Trouver du contenu similaire

🤖Kotlin DSL для AGSL-шейдеров на Android AGSL (Android Graphics Shading Language) появился в Android 13 как нативный язык шейдеров для GPU. Работает через RuntimeShader и RenderEffect, позволяет делать попиксельные эффекты на любом View или Composable. Но писать его больно: код живёт в строках, uniform-ы привязываются вручную, IDE не помогает. Библиотека RedByteFX оборачивает это в Kotlin DSL. Вот волновое смещение — сначала голый AGSL, потом то же самое через библиотеку: // Голый AGSL — строка в коде uniform shader content; uniform float wave_amplitude; uniform float wave_frequency; half4 main(float2 fragCoord) { float2 offset = float2( 0.0, sin(fragCoord.x * wave_frequency) * wave_amplitude ); return content.eval(fragCoord + offset); } // RedByteFX DSL val effect = redbytefx { val amplitude = uniformFloat(0f, "wave_amplitude") val frequency = uniformFloat(0.08f, "wave_frequency") val offset = let( float2(0f, sin(fragCoord.x * frequency) * amplitude), "wave_offset" ) sample(fragCoord + offset) } 🔗habr.com 🐱GitHub #Android

Вышла вторая Beta Android 17. Для разработчиков. Изменения произошли под капотом и в системном UI. 🔗 Анонс тут #Android#Android

💬 Как вы решаете, какие версии поддерживать, а какие нет? Какая у вас минимальная поддерживаемая версия сейчас? #Android

🤖Как не утонуть в океане версий Android: расставляем приоритеты в поддержке Каждый Android-разработчик сталкивался с этой болью: сотни версий ОС, десятки производителей с уникальными оболочками, тысячи моделей устройств. И все это нужно поддерживать. Или нет? Я считаю, что не нужно. И вот почему. Ресурсы тестирования конечны. Ваша команда — не Google с его армией QA-инженеров (да и им не хватает на всё). У вас ограниченное время, бюджет и люди. Попытка качественно поддерживать все версии Android, все оболочки вендоров и все устройства — прямой путь к выгоранию команды и багам в проде. Лучше отлично поддерживать 70-80% пользователей, чем посредственно — 100%. 1️⃣Анализируйте данные регулярно Google Play Console — ваш главный источник правды. Там есть всё: распределение по версиям Android, моделям устройств, размерам экранов. Альтернативно используйте Firebase Analytics, Amplitude или любую другую систему аналитики, которая у вас встроена. Важно смотреть на тренды. Если доля Android 6.0 упала с 5% до 1% за полгода — это сигнал пересмотреть поддержку. Рекомендую проводить такой анализ минимум раз в квартал, максимум — раз в год. Привяжите это к циклу планирования или мажорным релизам. 2️⃣Считайте не головы, а деньги У вас 1000 пользователей на Android 6.0? Звучит внушительно. Но задайте себе три вопроса: — Сколько из них активны за последний месяц? — Кто из них делает заказы / смотрит рекламу / оформляет подписки? — Какой у них engagement по сравнению с пользователями на свежих версиях? Если это мертвые души или их монетизация стремится к нулю — может, стоит сокращать поддержку этих версий ОС? Пример из практики: 1000 пользователей на Android 7 могут приносить $50/месяц, а 200 на Android 14 — $2000. Какую версию вам выгоднее поддерживать и проще? 3️⃣Сегментируйте пользователей Не все пользователи одинаково важны. Разделите их на категории: Сегмент A — высокий LTV, активные, платящие Сегмент B — средняя активность, периодические покупки Сегмент C — низкая активность, бесплатные пользователи Теперь посмотрите на распределение этих сегментов по версиям Android. Возможно, окажется, что ваши самые ценные пользователи уже давно на Android 10+, а на старых версиях сидят только "зомби". Это даст вам аргументы для приоритизации — и для разговора с бизнесом. 4️⃣Внедрите систему тиров поддержки Вместо бинарного "поддерживаем/не поддерживаем" используйте гибкую систему приоритетов: Tier 1 — Критичные версии Android 11-16 (условно — актуальные версии) Покрывают 70-80% вашей базы Уровень поддержки: полное ручное тестирование всех фичей перед каждым релизом, быстрые хотфиксы при багах Tier 2 — Важные версии Android 8-10 Покрывают еще 15-20% пользователей Уровень поддержки: проверка основных сценариев вручую + автотесты, хотфиксы по приоритету Tier 3 — Минимальная поддержка Android 7 Остаток пользовательской базы Уровень поддержки: только автотесты на smoke-сценарии, приложение работает, но активно не тестируется. Баги фиксим, только если они критичные Tier 4 — Best effort Всё, что осталось (Android 5-6 и старше) Совсем старые версии, которые еще технически поддерживаются Уровень поддержки: билд собирается, но тестирование отсутствует. Поддержка только на основе user reports Важно: границы тиров будут разными для каждого проекта. Ориентируйтесь на свою аналитику, а не на чужие цифры. 5️⃣Коммуникация с командой и стейкхолдерами Самое сложное — донести эту стратегию до бизнеса и команды. Для бизнеса важны цифры: сколько стоит (денег и времени) и сколько приносит, как можно инвестировать это время Для команды ценность понятна и так — четкие критерии избавляют от хаоса в процессах. Разработчики и QA будут знать, на что тратить время, а на что — нет. Также на принятие решение может влиять сложность поддержки старых версий Android, так как со временем Google и популярный Open Source постепенно откажется от этих версий. Apple вообще тут поступает жестко и убирает в XCode поддержку версий ОС. Например, сейчас Google поддерживает только Android 6.0+ #Android

🤖Посмотрел на обновлённую статистику распространения версий Android на 1 декабря 2025 и вот что интересно. 📈 Android 16 набирает обороты быстрее предшественников За два месяца после релиза Android 16 (API 36) уже захватил 7,5% рынка. Для сравнения, Android 15 (API 35) за аналогичный период имел всего 4,5%. Такой стремительный рост объясняется новой стратегией Google — Android 16 вышел раньше обычного (во втором квартале вместо третьего) и был разделён на два релиза. Это дало производителям больше времени на подготовку обновлений, и многие флагманы 2025 года уже выходили с Android 16 из коробки. ✔️ Минимальная версия: Android 7.0 всё ещё актуален Если смотреть на цифры, то Android 7.0 Nougat (API 24) и выше охватывает 99,2% устройств. Это значит, что отказавшись от поддержки Android 6.0 Marshmallow, вы теряете меньше 1% аудитории. Но помните — это глобальная статистика. Обязательно проверьте свою консоль Google Play: в некоторых регионах или нишах (например, бюджетные устройства для развивающихся рынков) картина может сильно отличаться. ⚖️ Что изменилось за 8 месяцев С апреля (пост с прошлой статой) по декабрь 2025 года произошёл серьёзный сдвиг поколений. Android 14 вырос с 31,9% до 44%, став фактическим лидером. Android 13 упал с 48,7% до 57,9% (кумулятивно), но всё ещё держит солидную базу. А вот старички Android 11 и ниже продолжают уверенно терять позиции — теперь на них меньше 30% устройств против 38,5% восемь месяцев назад. Интересно, что Android 15 за это время вырос до 26,8%, хотя многие производители только начали раскатывать обновления. Samsung, Xiaomi и другие гиганты обычно тянут с апдейтами до весны следующего года, так что пик Android 15 мы увидим ближе к середине 2026. 🏆Лидер всё тот же - Android 14 Самая популярная версия сейчас — Android 14 (API 34) с долей 44%. Это логично: устройства 2024 года выходили именно на этой версии, плюс многие флагманы 2023 года получили обновление. Android 13 на втором месте с 13,9% чистой доли (57,9% - 44% = 13,9%), но его позиции постепенно размываются. Для разработчиков это означает простую вещь: если вы таргетируетесь на API 34 (что обязательно для новых приложений в Google Play), вы автоматически находитесь на самой массовой платформе. А вот с минимальной версией стоит балансировать между охватом и необходимостью поддерживать легаси-код. Android 8.0 Oreo (API 26) даёт вам 98,4% охвата, что для большинства проектов более чем достаточно. 💬 В комментах делитесь совпадает ли статистика Google с реальностью вашего приложения #Android

🤖 Разбираюсь с системой разрешений в Android и снова упираюсь в один и тот же вопрос: почему до сих пор нет AndroidX‑решения, которое бы упростило всю эту рутину? В каждом проекте встречается тонны похожего кода для работы с разрешениями — и чаще всего без учёта лучших практик. Разработчики нередко просто запрашивают разрешение “в лоб”, не обрабатывая отказы корректно. Если пользователь отказал — то сразу перекидывают в настройки, и на этом всё. Google, кажется, слишком усложнила саму концепцию. Система разрешений должна была быть прозрачной и удобной для разработчика, но на практике реализована ею далеко не всегда. Один из выходов, который вижу — жёстче ревьюить сценарии работы с разрешениями и проверять, насколько реализация соответствует рекомендациям платформы. 💬Какой у вас опыт от запроса разрешений в Android? #Android

🏝Основы AGSL для android разработчика (17м) AGSL (Android Graphics Shading Language) — это язык программирования фрагментных шейдеров, представленный в Android 13 (API 33), который позволяет разработчикам создавать сложные графические эффекты, настраивать отрисовку Canvas и фильтровать содержимое View. Он глубоко интегрирован в графический движок Android (Skia), что позволяет применять GPU-ускоренные эффекты напрямую к стандартным элементам интерфейса . Классная статья, которая описывает простым языком как рабоатет AGSL и какие преимущества дает разработчикам, а также как его начать использовать #Android

Вот бы классно чтобы все как Uber перешли на Credential Manager API и перенос аккаунтов стал проще для пользователей, а бизнесу дешевле Подробности в статье от разработчика #android

🤖Получи ранний доступ к новой системе верификации Android разработчиков Google открыла прием заявок к раннему доступу в консоль верификации Android разработчиков, которые распространяют приложения за пределами Google Play. Подробности про систему в видео Подать заявку можно тут (ссылка без спец средств не работала из Беларуси) #android

🤯 Бесполезный выключатель "Работа в фоне для приложения". Зачем всё это? #android

🤖Есть ли чувство юмора у разработчиков Android SDK? Однозначно — да! В исходниках можно найти такие шедевры 👇 // Проверяет используется ли сейчас Monkey Runner ActivityManager.isUserAMonkey() UserManager.isUserAGoat() UserManager.DISALLOW_FUN // Отдали дань памяти хиту Chronometer.isTheFinalCountdown() Log.wtf() // Попало в релиз, хотя явно должно было быть исправлено AdapterViewFlipper.fyiWillBeAdvancedByHostKThx() // Звёздные войны SensorManager.GRAVITY_DEATH_STAR_I Разработчики в Google точно любит пошутить 😄 А вы где встречали весёлые названия API или переменных — в Android, KMP или своих проектах? #android

🤖Появились уточнения касательно процесса верификации Android разработчиков ‼️ Самое важное - разработчики всё также смогут ставить приложения без регистрации через ADB. Вот она лазейка 😁 #android