Задні та додаткові екрани смартфонів: API, сценарії та обмеження

Оновлено: 6 листопада 2026.

Задній дисплей смартфона може бути повноцінним екраном Android, закритою системною панеллю, поверхнею для окремого вікна або світлодіодною матрицею із власним SDK. Ці варіанти виглядають схоже лише здалеку. Для розробника у кожного свій вхід, життєвий цикл та набір обмежень.

Телефон лежить екраном униз. На звороті видно таймер. Інша людина зчитує квиток, доки власник тримає пристрій основним екраном до себе. На складаному телефоні співрозмовник бачить переклад. Сценарії привабливі, але починати потрібно із запитання: який програмний контракт дозволяє нашому застосунку показати ці дані?

Зріз дослідження — 5 листопада 2026 року. У таблицях окремо позначені функції користувача, документовані API та непідтверджений доступ. Ілюстрації — авторські концепти. Фізичні пристрої у межах цього дослідження не тестувалися; наявність сторінки продукту не вважається перевіркою сумісності програми.

1. П'ять різних технологій за словом «другий екран»

Це перша розвилка архітектури. Якщо ОС уже переносить звичайну програму на вузький екран, потрібен хороший адаптивний інтерфейс. Якщо панель належить до системного сервісу, зміна CSS або Compose не відкриє доступу до неї. Якщо це матриця Nothing, WindowManager узагалі не є основним інструментом її програмування.

2. Карта пристроїв: де підтверджено інтерфейс, а де тільки функція

Таблиця не означає, що для перелічених моделей існує єдиний SDK. Негативний результат дослідження також сформульований вузько: «публічний API не підтверджений у перевірених матеріалах». Це не є доказом відсутності закритих партнерських угод чи майбутнього оновлення.

3. Xiaomi: системні картки не дорівнюють відкритому canvas

На сторінці Xiaomi 17 Pro Max описані стани доставки, поїздки та рейсу, керування музикою та дзвінками, камерний перегляд, перенесення зображення або QR на задню сторону. Частина функцій потребує конкретних оновлень. Для продукту це хороші приклади поведінки, але поки що не інструкція з підключення APK.

Навіть якщо власник телефону може створити особисту картку через AI-редактор, це не доводить існування API, куди сторонній застосунок відправить стан замовлення. Редактор користувача, партнерська інтеграція та публічний SDK вирішують різні завдання. Аналогічно доступ до Xiaomi Super Island не є автоматичним дозволом малювати на задньому екрані.

Для Xiaomi 18 Pro не можна механічно переносити контракт попереднього покоління. Згадки нових AI-карток та їх кількості не використовуємо як обіцянку розробницької доступності: у перевірених відкритих матеріалах не вдалося підтвердити загальний rear-display SDK із довільним відмальовуванням для стороннього APK. Для оцінки конкретної інтеграції потрібна назва API, документація, умови допуску, список моделей/прошивок та приклад запуску.

Практичне рішення для команди: зафіксувати цю можливість як таку, що потребує підтвердження, запросити умови відповідного каналу у виробника та продовжити реалізацію вже доступних системних поверхонь. Не продавати замовнику "підтримку заднього екрана Xiaomi" на підставі скриншоту чужого сервісу.

4. Nothing Glyph Matrix: реальний SDK, два різні способи роботи

Офіційний Glyph Matrix Developer Kit документує керування кадрами з програми та окремі Glyph Toys. Це конкретний публічний спосіб доступу. Він відрізняється від Glyph Interface SDK для світлових сегментів: однаковий бренд не робить обладнання та методи взаємозамінними.

Для програми послідовність така: підключити відповідну бібліотеку, оголосити com.nothing.ketchum.permission.ENABLE, створити GlyphMatrixManager, викликати init(callback), після підключення зареєструвати підтримувану модель та передавати кадри через setAppMatrixFrame(). При закінченні виводу використовується closeAppMatrix(), а з'єднання звільняється через unInit().

Тут "зареєструвати" означає виклик SDK для вибраної моделі. Не слід переказувати як обов'язкове індивідуальне партнерське узгодження кожного застосунку. Окремо перевіряються умови використання комплекту та вимоги розповсюдження.

Для Toy потрібен сервіс із передбаченими SDK action, metadata та preview. Система викликає його під час вибору користувачем; робота запускається у bind та зупиняється у unbind. Обробник взаємодій приймає документовані події через Messenger. Якщо модель не підтримує Glyph Touch, не можна малювати інструкцію "затисніть кнопку" і вважати завдання вирішеним. У поточному комплекті Phone (4a) Pro описаний як варіант AOD Toys без Glyph Touch.

Для розробки корисно зберігати маленький візуальний словник: кільце — процес; нерухомий знак — пауза; короткий завершальний малюнок — готовність. Це авторська рекомендація, а не стандарт Nothing. Не перетворюйте кожне завдання на безперервну анімацію: перевіряйте витрату енергії, зрозумілість сигналу та поведінку, коли система показує пріоритетніший Toy.

5. Ulefone: спочатку адаптуйте звичайну програму

Ulefone описує чотири режими: основний екран, задній екран, перемикання між ними та дзеркало. У дзеркальному режимі обидві сторони показують один вміст, а введення приймає одна вибрана сторона. Розбір виробника прямо відокремлює це від двох незалежних застосунків.

Для Armor 30 Pro специфікація заднього дисплея вказує 3,4 дюйми та 412 × 960 фізичних пікселів. Це не 412 × 960 dp та не готова ширина CSS viewport. Щільність, системні панелі та налаштування масштабу впливають на простір програми. У деяких рекламних описах характеристики розходяться; для інженерного рішення потрібні специфікація та вимірювання вікна на пристрої.

Якщо Android переносить вашу програму на задню сторону, окремий OEM SDK може не знадобитися. Перевірте збереження форми та стану навігації при зміні екрана; доступність основної кнопки при відкритій клавіатурі; перенесення довгих підписів; прокручування; орієнтацію та призначення активної сенсорної сторони.

Не копіюйте на таку поверхню складну адміністративну таблицю. Для підтвердження видачі замовлення достатньо його номера, поточного стану та однієї зрозумілої дії. Деталі залишаються в основному процесі. Маленький фізичний екран особливо швидко виявляє інтерфейси з фіксованою висотою та кнопкою, яку неможливо дістати.

6. DisplayManager + Presentation: окремий вміст на доступному дисплеї

DisplayManager дозволяє отримати дисплеї, які підходять для презентацій. Це список кандидатів, а не спосіб розблокування закритої панелі виробника:

val displayManager =
    getSystemService(Context.DISPLAY_SERVICE) as DisplayManager
val candidates = displayManager.getDisplays(
    DisplayManager.DISPLAY_CATEGORY_PRESENTATION
)

Не вибирайте перший елемент наосліп: ним може бути підключений монітор, а не задня сторона телефону. Ідентифікатор дисплея не повинен бути заздалегідь жорстко заданий як 1. Потрібно зрозуміти, який екран призначений для поточного сценарію і чи він доступний у поточному стані пристрою.

val presentation = object : Presentation(this, selectedDisplay) {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(TextView(context).apply {
            text = "Замовлення готове до видачі"
            textSize = 24f
        })
    }
}
try {
    presentation.show()
} catch (error: WindowManager.InvalidDisplayException) {
    showDisplayUnavailable(error)
}

Це фрагмент з Activity: selectedDisplay та showDisplayUnavailable надає ваша програма. Макет створюється через контекст Presentation, щоб використовувати ресурси потрібного екрана. За контрактом Presentation виклик show() може викинути InvalidDisplayException, навіть якщо дисплей був знайдений раніше. Обробіть видалення екрана, зупинку власника, зміну геометрії та звільнення власних слухачів.

Запуск окремої Activity — інший шлях

Для нього перевіряють FEATURE_ACTIVITIES_ON_SECONDARY_DISPLAYS, а на відповідній версії - ActivityManager.isActivityStartAllowedOnDisplay(...). Дисплей задають через ActivityOptions.makeBasic().setLaunchDisplayId(...). Перевірка та спосіб запуску мають різні мінімальні версії API. Документація ActivityOptions попереджає про обмеження приватних дисплеїв; звичайні правила запуску Activity з фону також продовжують діяти.

Якщо запуск заборонено, коректний результат — зрозумілий стан недоступності. Приховані API, root і оверлей поверх основного екрана не перетворюють його на інтеграцію, що підтримується.

7. WindowAreaController: перенесення та подвійний екран у складаних пристроїв

Jetpack WindowManager описує окремі операції: перенесення Activity на задню область та показ додаткового вмісту одночасно з основним. У посібнику з режимів складаних екранів для них використовуються capability-перевірки та сесії.

Порядок роботи: знайти відповідну область → перевірити конкретну операцію → розрізнити unsupported, unavailable, available та active → запитати перенесення чи presentation → зберегти отриману сесію → обробити її завершення. Система може закрити сесію, коли змінюється положення пристрою або доступність режиму. Це подія життєвого циклу, а не обов'язково помилка програми.

Звіряйте приклади із встановленою версією androidx.window. У документації зустрічаються покоління API з WindowAreaInfo та transferActivityToWindowArea, а нові reference-сторінки містять WindowArea та transferToWindowArea. Змішування старого керівництва та нового alpha-символу дає код, який не збирається.

Цей механізм особливо зрозумілий на сценарії двостороннього перекладу: власник бачить управління, співрозмовник — великий текст. Але наявність WindowAreaController не доводить доступ до маленького AMOLED Xiaomi, довільного віджета на Flip або Glyph Matrix.

Як перебудовувати основний інтерфейс Flip/Fold

Під час перенесення між зовнішнім та внутрішнім екраном змінюються не тільки розміри. Потрібно перевірити доступну висоту, щільність, safe areas, клавіатуру, стан та геометрію згину. У вузькому вікні список і деталі можуть відкриватися послідовно, а в широкому — поруч. Вибраний об'єкт, чернетка, позиція читання та операція, що виконується, повинні зберігатися.

Для напівзігнутого пристрою розміщення перегляду та керування в різних областях корисне лише у відповідному сценарії та за достовірних даних про положення. Фізичний шарнір, складка, що не закриває пікселі, і звичайна зміна вікна — різні умови. На сайті наявність Fold не гарантує, що браузер повідомить сегменти.

Практичний розділ у загальному огляді показує чотири варіанти одного інтерфейсу та порядок перевірки. Для реалізації є окремий скіл Adaptive Interfaces для сайтів та застосунків; інструкція встановлення знаходиться поряд із оглядом. Він доповнює перевірку доступу до дисплея та не замінює її.

8. Що може сайт та PWA

Якщо ОС відкриває браузер на задньому екрані, сайт адаптується до реального вікна: responsive layout, доступні кнопки, коректна клавіатура та прокручування. Вебзастосунку не обов’язково знати модель телефону, щоб добре працювати у вузькій області.

Є й окрема Window Management API для розміщення браузерних вікон на кількох екранах. Її потрібно перевіряти через feature detection та дозволи, наприклад перед зверненням до window.getScreenDetails(). Це API вікон браузера на доступних екранах; воно не дає прямого доступу до закритого rear-panel сервісу та не замінює Glyph SDK.

Звичайне встановлення PWA також не додає ActivityKit. Якщо проєкту справді потрібна нативна інтеграція, необхідно окремо спроєктувати нативний компонент, канал даних та його життєвий цикл. Не можна обіцяти це як побічний ефект адаптивної верстки.

9. Що показувати: короткий стан та усвідомлена дія

Для таймера корисний час, що залишився. Для завдання — достовірний етап і завершення. Для показу іншій людині — спеціально підготовлена публічна версія: номер видачі, дозволений квиток, текст перекладу. Перехід у режим «показати» має бути зрозумілий власнику.

Сценарій AI-генерації добре виявляє ризик: якщо сервер перестав відповідати, «телефон живе» не повинен означати, що на корпусі продовжується вигаданий прогрес. Світловий малюнок може означати очікування, але стан «дані застарілі» має бути помітним, а підтверджена готовність з'являтися тільки після завершення завдання.

QR вимагає реального вмісту, достатньої площі, контрасту, вільної зони та перевірки сканером. Монохромна матриця з невеликою кількістю точок не стає надійним квитковим дисплеєм через те, що на ній вдалося намалювати схожий візерунок. Використовуйте справжню систему випуску та перевірки пропуску, а не декоративну картинку.

Не виводьте автоматично особисті повідомлення, коди підтвердження або медичні дані на сторону, яку бачать оточуючі. Блокування основного екрана не доводить, що додаткова поверхня приховала вміст. Зміна облікового запису та вихід повинні прибирати подання, що стосуються до нього.

10. Перевірка на пристрої та рішення про випуск

Вимірюйте користь у конкретному сценарії: чи вдалося швидше дізнатися про стан, уникнути повороту телефону, показати потрібну інформацію або виконати дію. Кількість спалахів, кадрів та відкриттів програми не є самостійною цінністю.

Хороший перший випуск — один зрозумілий сценарій на підтвердженому пристрої: таймер у Glyph Matrix, адаптивна видача замовлення на Ulefone або двосторонній переклад через Window Area, що підтримується. Розширювати охоплення слід після перевірки доступу та життєвого циклу. Загальна модель завдання може бути однією; кожний додатковий екран залишається окремою інтеграцією.

Застосувати посібник з Codex та Claude Code

За результатами цього дослідження ми створили відкриті скіл Interaction Surfaces для Codex і Claude Code та скіл Adaptive Interfaces. Вони допомагають проаналізувати наявний сайт або застосунок, визначити доступні API й запропонувати корисні сценарії: віджети, поточні активності, годинники, додаткові екрани та адаптацію інтерфейсу. Ви вибираєте, що впровадити, відкласти чи виключити; потім агент реалізує вибрані зміни й перевіряє результат у межах доступних платформ і пристроїв.

Для роботи над своїм застосунком можна встановити скіл Interaction Surfaces з GitHub. У ньому є перевірка доступу до екрана, DisplayManager та Presentation, WindowManager, Glyph Matrix та правила синхронізації з основною програмою. Англійський пакет охоплює усю серію; інструкція зі встановлення та приклад виклику знаходяться у загальному огляді.

Часті запитання

Чи є універсальний Android API для всіх задніх екранів?

Немає єдиного контракту, який відкриває будь-яку панель. Існують стандартні механізми кількох дисплеїв, WindowManager та фірмові SDK; спочатку потрібно встановити, до якого з них належить пристрій.

Чи можна обійтися без SDK виробника?

Так, коли ОС вже запускає звичайну програму на потрібному екрані або надає стандартний доступ до дисплея. Для системних панелей із закритим доступом це не працює автоматично.

Якщо є редактор анімацій користувача, значить є SDK?

Ні. Редактор може зберігати зображення для системної функції, не надаючи програмі ні викликів, ні подій, ні права відображати поточні дані.