Появились слухи, что Samsung отложила на неопределенный срок выпуск для своих телефонов обновление Android 15 и бета-версии основанной на этой версии ОС прошивки One UI 7. Новости поступили от известных инсайдеров IceUniverse и Chun Bhai, опубликовавших, что все еще нет планов по запуску в ближайшем будущем. Именно Чун Бхай сказал, что обновление отложено на неопределенный срок.

Судя по всему, Samsung испытывает много проблем с запуском обновления, несмотря на ряд утечек, показавших новый увлекательный набор визуальных изменений и функций, включая переработанный интерфейс камеры, разнообразные новые скины и функцию, вдохновленную Динамическим островом Apple.

Нынешняя новость появилась после предварительной задержки в конце июля, когда Samsung отложила выпуск бета-версии Android 15, поскольку решила сосредоточиться на публичном выпуске One UI 6.1.1 для серии Galaxy S24.

Причина задержки не ясна. Это могут быть ошибки и проблемы с обновлением, но главной проблемой, кажется, является задержка развертывания прошивки One UI 6.1.1, которая отбросила все назад. Пока маловероятно, что обновление Android 15 может быть готово к запуску в августе.

Хорошая новость для Samsung состоит в том, что она не единственная в задержках обновления. Google также отложила развертывание Android 15, поскольку, по слухам, будущая серия смартфонов Pixel 9 будет выпущена из Android 14. Последний августовский патч также вышел на основе Android 14, поэтому мы вряд ли увидим Android 15 от Google раньше сентября, что означает, вероятно, его доступность еще позже для смартфонов Samsung.

Пока нет информации о том, как долго продлится эта задержка, или какой-либо конкретной информации о том, когда ожидать новую прошивку на новой версии ОС. Первым признаком того, что это, вероятно, произойдет в скором времени, будет, когда исправления Android, которые начнут выходить, будут базироваться на Android 15, а не на Android 14.

В бойлере горячая вода может закончиться внезапно, например, когда вы принимаете душ, что неприятно. Избежать этого можно с помощью искусственного интеллекта, считают в компании Cala Systems из Бостона. Эта фирма выпускает бойлер с искусственным интеллектом.

Водонагреватели, как правило, являются достаточно простыми приборами, которые в своей основе у них три основные части: изолированный бак, нагревательный элемент и термостат. Большинство людей установили температуру один раз и забыли. В редких случаях температуру могут несколько раз изменить. Когда горячая вода убирается из бака, холодная вода заменяет ее, снижая температуру внутри. Когда температура становится достаточно низкой, термостат сообщает нагревателю включиться.

Основная технология большинства водонагревателей, газовых или электрических почти не изменилась в течение нескольких десятилетий. Их можно купить дешево, но недешево использовать.

«Это действительно устаревшее, – сказал директор Cala Systems Майкл Ригни. — Мы можем улучшить в 2024 году».

Он основал компанию Cala Systems в Бостоне в 2020 году, когда водонагреватели с тепловыми насосами начали развиваться.

Водонагреватель Cala Systems сочетает тепловой насос с системой управления на основе искусственного интеллекта, чтобы прогнозировать потребность в горячей воде и соответствующим образом нагреть воду в баке.

Компания собирает общую информацию, например прогнозы погоды и цены за продолжительность использования энергии, и посылает ее в водонагреватель.

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

Анализируя модели использования воды, водонагреватель может предусмотреть, когда будет резкий спрос, и нагреть воду эффективным способом.

К примеру, если погода предусматривает несколько солнечных дней перед парой дней облаков, алгоритмы Cala могут решить использовать дневную энергию от солнечных панелей домовладельца, чтобы перегреть резервуар. Затем, когда требуется горячая вода, она смешивается с холодной, чтобы остыть до соответствующей температуры. Это позволяет водонагревателю максимально использовать избыток солнечной энергии, фактически превращая резервуар в батарею, которая сохраняет энергию в пасмурный день.

В других случаях, когда потребность в воде постоянны, водонагреватель Cala может замедлить скорость компрессора, продлевая время, необходимое для нагрева бака для повышения эффективности. «В водном нагревании, когда вы замедляете компрессор, вы увеличиваете эффективность теплопередачи примерно на 30%. – сказал Ригни. – Это достаточно значительное влияние».

А если в дом придут гости? Cala включает в себя режим усиления, который люди могут активировать на бойлере или в приложении.

Водонагреватели с тепловыми насосами могут составлять лишь несколько процентов рынка, но их доля быстро растет. И хотя их дороже установить заранее, они дешевле в долгосрочной перспективе, поскольку они более эффективны в эксплуатации.

Google содержит огромный массив данных, для оптимизации и более быстрой доставки которого нужно ежедневно перемещать данные между внутренними серверами. Объем такого перемещения настолько велик, что доступные инструменты не подходят и пришлось создать свой.

Google раскрыл технические детали своего внутреннего инструмента передачи данных под названием Effingo и похвастался, что использует этот проект для перемещения в среднем 1,2 экзабайта в день.

Как поясняется в документе [PDF], представленном на конференции SIGCOMM 2024 в Сиднее, ограничение пропускной способности и упорная постоянная скорость света означают, что даже Google не застрахован от необходимости копировать данные, чтобы они находились вблизи там, где их обрабатывают или отдают пользователям.

Документ описывает управляемую передачу данных как «невоспетого героя крупномасштабных, глобально распределенных систем», поскольку она уменьшает задержку сети сотен во всем мире до десятков миллисекунд на континенте.

В документе также указывается, что инструменты передачи данных найти нетрудно, и спрашивается, зачем нужен такой уровень управления, как Effingo.

Ответ заключается в том, что инструменты, которые Google мог найти, были оптимизированы для времени передачи или обрабатывали потоки данных «точка-точка» — и они не справлялись с задачей обработки 1,2 экзабайта, которые Effingo перемещает в среднем в день со скоростью 14 терабайт в секунду.

Чтобы справиться с задачей, Effingo сбалансирует эффективность инфраструктуры и потребности пользователей и признает некоторые пользователи и некоторые передачи важнее других: например, аварийное восстановление обслуживающей базы данных по сравнению с миграцией данных из кластера с обслуживанием запланировано через неделю.

Инструмент должен гарантировать, что задачи получают необходимую производительность, и гарантировать, что если задачи имеют одинаковый приоритет, они оба получают надлежащий уровень ресурсов, а не борются за IOPS, пропускную способность или вычислительные ресурсы.

Как Google это делает?

В документе объясняется, что Effingo оптимизирован для файловой системы Colossus, разработанной и используемой собственными силами Google, обычно разворачивающейся в кластерах, содержащих тысячи машин.

Effingo развернут в каждом кластере. Его программный стек включает в себя плоскость для управления жизненным циклом копии и плоскость данных, которая передает байты и отчитывается о состоянии. «Код и потребление ресурсов неравномерны: плоскость данных использует 99 процентов ЦБ, но занимает менее семи процентов строк кода», — говорится в документе.

Каждый кластер подключен к каждому другому – некоторые внутри центра обработки данных в сети CLOS с низкой задержкой и высокой пропускной способностью. Другие полагаются на соединения WAN, использующие инфраструктуру Google и сторонних разработчиков.

Независимо от технологии, лежащей в основе глобальной сети, присутствует инструмент под названием Bandwidth Enforcer (BWe).

BWe – это еще один проект Google, предназначенный для распределения пропускной способности на основе приоритета обслуживания и стоимости, полученной путем добавления дополнительной пропускной способности. BWe определяет «классы сетевых услуг» (NSC), и все потоки трафика в Google обозначаются одним из предопределенных NSC.

Когда пользователь инициирует перенос данных, Effingo запрашивает распределение трафика от BWe и приступает к перемещению как можно скорее.

Такое распределение трафика может происходить на основе заранее определенных квот, которые Google определяет с помощью метрик для входящей и исходящей полосы пропускания на кластер, IOPS и доступных воркеров Effingo – кода, который обрабатывает перемещение данных и выполняется как задача Borg. Borg — это контейнерная платформа, созданная Google как Kubernetes.

Effingo может делать ставки на использование ресурсов, определенных квотой, для рабочих нагрузок, требующих определенной производительности сети. Инструмент также может полагаться на лучшие ресурсы менее критических потоков.

Даже несмотря на всю работу по распределению ресурсов, Effingo имеет средний глобальный размер резерва в 12 миллионов – обычно около восьми петабайт. Даже в самый лучший день в очереди стоит около двух миллионов файлов. Отставание возрастает примерно на 12 петабайт и девять миллионов файлов, когда десять крупнейших пользователей сервиса начинают новые передачи.

В технологиях экранов назревает переход на новую строчку достижения поразительной картинки – это технология OLED с голубым люминофором, известна также под названием phOLED. Люминофорный OLED-материал является более эффективным, обеспечивает большую яркость, требуя меньшего количества энергии, поэтому работает холоднее. Эта технология уже используется в OLED-пикселях для чтения и зеленых пикселях, но синие пиксели оказались самыми сложными в производстве. Из-за производственных проблем массовый запуск таких экранов недавно был отложен на несколько лет.

Blue phospor OLED был следующей обширной технологией в телевизионных технологиях в течение некоторого времени, и такие фирмы, как LG и Samsung, рассматривают возможность их использования.

Но, похоже, на пути к светлому OLED-будущему возникли небольшие затруднения. Согласно последним финансовым результатам Universal Display Corporation, фирмы, разрабатывающей технологию OLED с голубым люминофором, коммерциализация технологии займет чуть больше времени, чем ожидалось.

Хорошие новости? Дополнительное время измеряется месяцами, а не годами, и компания ожидает, что коммерческий синий phOLED материал будет готов в 2025 году.

Почему PHOLED является фантастическим

Цифры производителей всегда следует делить навел. Но теоретически phOLED-дисплеи способны достигать 100% внутренней световой эффективности по сравнению с 25% аналогов из флуоресцентного материала, являющегося основой синих пикселей OLED. Это означает, что вы можете достичь более высокой яркости без увеличения количества тепла, которое выделяют пиксели.

Красные и зеленые phOLED оказались сравнительно легкими в изготовлении, но синие являлись более сложной задачей: еще в 2022 году производители не смогли создать стабильные синие phOLED излучатели. Это изменилось в 2022 году, и ожидалось, что мы увидим голубые phOLED на панелях телевизоров и возможно также на смартфонах до 2024 года, но это оказалось слишком оптимистичным.

Из сообщения UDC неизвестно, почему была вызвана задержка. Но отчеты говорят о том, что компания борется за эффективность и долговечность. В отчете The Elec в конце 2023 года говорится, что Samsung перенесла свои планы по синим phOLED на вторую половину 2025 года, годом позже, чем планировалось ранее; Комментируя этот шаг, аналитики UBI Research заявили, что синие phOLED все еще страдают от «низкого срока службы» примерно на 55% по сравнению с существующими флуоресцентными синими OLED.

Итак, пока лучшие телевизоры не будут снабжены синими пикселями phOLED. Но эта технология остается многообещающей и должна обеспечивать более яркие телевизоры без ущерба для долговечности. Следует ожидать результатов до 2026 или даже 2027 года.

Начиная с Android 15 приложения по умолчанию вынуждены работать от края к краю, что делает панель состояния и навигацию прозрачными. Однако Google тихо добавил программный интерфейс (API), посредством которого приложения могут отказаться от этого принуждения. Однако этот API не упоминается ни в каких документах разработчиков Google, публикациях блога или программистских лабораториях.

Есть много причин, почему разработчики уклонялись от того, чтобы сделать свои приложения полноэкранными, но в предстоящем обновлении Android 15 у них не будет иного выбора.

Для короткого контекста: программы уже давно могут работать от края к краю, реализуя несколько API, сообщающих ОС отображать приложение под двумя системными панелями (т.е. панелями состояния и кнопками навигации). Причина того, что Google не сразу применил такое поведение, заключается в том, что многие программы могут испытывать проблемы с пользовательским интерфейсом, если их заставляют работать от края к краю. Например, в приложении может быть интерактивный элемент, например плавающая кнопка действия, которая будет перекрывать панель навигации, если она перейдет от края к краю.

Чтобы решить эту проблему, Google дал разработчикам способ устранить перекрытия с помощью вставок, определяющих, какие части экрана программы пересекаются с интерфейсом системы. Однако из-за того, что приложения никогда не работали от края к краю, многим разработчикам не нужно было беспокоиться о разрешении этих конфликтов пользовательского интерфейса.

Когда Google анонсировала Android 15 Beta 1 в начале этого года, Google анонсировала Android 15 Beta 1, она показала, что приложения, нацеленные на Android 15, будут по умолчанию отображаться от края к краю. Чтобы помочь разработчикам с этим переходом, Google опубликовал новые документы для разработчиков, учебные пособия и лабораторные кодовые работы, которые демонстрируют, как управлять этим в Android 15.

Однако ни в одном из этих руководств не упоминается, что на самом деле существует API, который приложения могут использовать, чтобы отказаться от режима от края к краю.

Рассматриваемый API является атрибутом, который называется windowOptOutEdgeToEdgeEnforcement, какие программы могут установить значение true в своих файлах тем. По умолчанию атрибут имеет значение false, что означает, что к окну будет применен контроль от края к краю, если оно является частью приложения, нацеленного на Android 15. Однако если для атрибута установлено значение true, то соблюдение режима от края к краю не будет применено в соответствующее окно.

Однако описание API предупреждает, что этот атрибут будет устаревшим и выключенным на будущем уровне SDK, что означает, что этот обходной путь не будет вечно. Google Play Store не будет принуждать приложения нацеливаться на Android 15 до 31 августа 2026 года.