Задние и дополнительные экраны смартфонов: 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?

Нет. Редактор может сохранять картинки для системной функции, не предоставляя приложению ни вызовов, ни событий, ни права показывать текущие данные.