Ядро собрать с поддержкой изоляции namespases и всё всегда работало без проблем.
Лично в моем понимании, если идти в сторону сборки ядра или подобных изменений, то проще уже поставить pmOS как минимум для экономии ресурсов устройства(pmos потребляет гораздо меньше) и большей гибкости
Я это не упомянул в статье, но у меня именно вариант без UI
Не удалось настроить отключение по достижению процента зарядки
Возможно, что мой сервис поддержания зарядка подойдет
не видит доп. SD карту через SIM разъем. Хотя, например, TWRP с ней может работать
TWRP работает на ядре под Android систему, поэтому там есть все нужные патчи под железо телефона. Можно посмотреть, как обвязка sd карты сделана в android ядре и пропатчить ядро в pmos, но задачка не такая простая
огорчило то, что не работает dual режим с зарядкой по OTG . Пока что либо зарядка, либо работа с устройствами в USB HUB
Тоже проблема поддержки mainline ядро, можно попробовать поизучать android ядро с агентами и сделать патчи для себя
В целом, можно использовать в качестве сервера для каких то не сильно нагруженных вещей. У меня там Hermes агент, например
Тоже есть идея хостить OpenClaw/Hermes, заодно посмотреть на то, как железо телефона справится с двумя сервисами
Есть мысль: заменить акум на ионистор. В таком случае вроде как "батарея есть" и контроллер не будет с ума сходить, в то же время в случае скачков напряжения он поможет.
Можно собрать любую подходящую по характеристикам батарею, лично мне не хочется вандалить телефон и заниматься сборкой подобного
Я бы с удовольствием почитал про такую доработку, если решите сделать и рассказать об этом
Вопрос по питанию — разве околонулевая зарядка лучше, чем хождение в диапазоне 30-60%, например?
Уже ответили выше, но да, в целом лучше держать заряд на одном уровне. Литий так меньше интеркалируется в анод, таким образом удается держать объем анода на одном уровне. Меньше дельта изменения объема = меньше износ
И второй момент — можно развернуть ещё Caddy, тогда можно будет свои локальные домены использовать без пути от Tailscale.
Если честно, то не изучал вопрос тк в моем случае я не хотел выставлять бота в публичный доступ извне моей mesh-сети. Как я понимаю, то можно запустить и настроить все, что поддерживает pmOS тк это обычный линукс
У самого OnePlus 5T лежит и только форвадит СМС, тоже хочу сделать что-нибудь из него на помощь своему домашнему серверу
Есть несколько моментов, на которые стоит обратить внимание:
Если хочется именно чистый Linux, как в моем случае, то сначала нужно проверить, можно ли разблокировать загрузчик на телефоне. Насколько я помню, Op5t разблокируется не сложнее, чем Op3t
Насколько хорошо SoC и платформа в целом поддержаны в mainline Linux или наличие форков под конкретные устройства. Можно и самому доработать, но затратно по ресурсам
Еще есть вариант попробовать сделать в Termux, но того уровня гибкости, который дает полноценная система не получить
1) в чем по-вашему выражается сильная связь? 2) чем может помочь path навигация? если это выглядит так, как в примере ниже, то в android от этого очень долго пытались уйти в навигации от гугл и наконец ушли тк типизированная в контексте android подходит гораздо больше
entry("/path/to/screen")
3) чем плох config based router в контексте android разработки?
У вас есть 3 экрана под скоупом AuthGraph. нужно чтобы при попадании в AuthGraph (не важно, в какой экран) у вас отработал метод fetch() при старте. Можете, пожалуйста, написать небольшой пример, как вы сделаете вызов? Важно, чтобы вызов был один раз за все время жизни AuthGraph.
Например, создаю AuthFeatureViewModel
Скрытый текст
class AuthFeatureViewModel : ViewModel() {
init {
// do something
}
}
Помещаю ее в скоуп фичи
Скрытый текст
val authModule = module {
scope<Screen.AuthGraph> {
viewModelOf(::AuthFeatureViewModel)
}
}
Подскажите, пожалуйста, думали ли в сторону того, чтобы создавать скоупы, не привязывая их к вьюмоделям?
Да, изначально пробовал делать без них. Уперся в то, что без ViewModel не получалось понять, в какой момент закрыть скоуп фичи.
И второй вопрос касательно вашего подхода: как выполнять операции, которые должны совершаться единожды при создании родительского скоупа?
Для такого я создаю ViewModel, в скоупе фичи и выполняю действие внутри нее
Мы у нас на проекте сделали немного вычурно – создаем composable с navHost`ом, где описываем дочерние экраны –порождает огромное кол-во контроллеров, но зато есть возможность описать родительский контекст в одном месте, а не в каждой функции
А вы уже обрабатывали кейс, когда нужно передавать параметры в объект, который живет в рамках скоупа фичи? Это отдельное приключение
Для себя я только такой и рассматриваю, подключение по ssh, можно собрать кастомный дашборд со статами железа, если понадобится
Можно, но нет желания заниматься: вырезать гугл сервисы, каким-то образом отключать systemui и другие вещи, слишком много доп работы
Не такая большая проблема в целом, можно использовать https://github.com/libhybris/libhybris и оставаться в рамках android блобов и ядра
pmOS с огромным отрывом выигрывает по расходу ресурсов, что не менее важно
Лично в моем понимании, если идти в сторону сборки ядра или подобных изменений, то проще уже поставить pmOS как минимум для экономии ресурсов устройства(pmos потребляет гораздо меньше) и большей гибкости
Не представляю, как полноценный сервис, который нужно хостить, упаковать в android приложение, чтобы оно нормально работало
Это даже не учитывая всех тех проблем, что андроид потребляет больше ресурсов, нужно настраивать вейклоки и прочие вещи по отключению энергосбережения
Поддерку можно проверить в официальной wiki pmOS: https://wiki.postmarketos.org/wiki/Xiaomi_Redmi_Note_3_(xiaomi-kenzo)
У Kenzo все выглядит довольно неплохо
Я это не упомянул в статье, но у меня именно вариант без UI
Возможно, что мой сервис поддержания зарядка подойдет
TWRP работает на ядре под Android систему, поэтому там есть все нужные патчи под железо телефона. Можно посмотреть, как обвязка sd карты сделана в android ядре и пропатчить ядро в pmos, но задачка не такая простая
Тоже проблема поддержки mainline ядро, можно попробовать поизучать android ядро с агентами и сделать патчи для себя
Тоже есть идея хостить OpenClaw/Hermes, заодно посмотреть на то, как железо телефона справится с двумя сервисами
У Android есть много ограничений
всю подобную инфраструктуру нужно разворачивать через Termux те минус гибкость
Без глубоких доработок системы/пересборки, нельзя убрать гугл сервисы и прочие потребляющие ресурсы вещи
Ограничения/оптимизации андроид по питанию нужно обходить отдельно
pmOS без ui после запуска потребляет ~200-300MB RAM и 0% CPU, с андроид даже сравнивать не стоит
Удалено
Можно собрать любую подходящую по характеристикам батарею, лично мне не хочется вандалить телефон и заниматься сборкой подобного
Я бы с удовольствием почитал про такую доработку, если решите сделать и рассказать об этом
Уже ответили выше, но да, в целом лучше держать заряд на одном уровне. Литий так меньше интеркалируется в анод, таким образом удается держать объем анода на одном уровне. Меньше дельта изменения объема = меньше износ
Если честно, то не изучал вопрос тк в моем случае я не хотел выставлять бота в публичный доступ извне моей mesh-сети. Как я понимаю, то можно запустить и настроить все, что поддерживает pmOS тк это обычный линукс
Есть несколько моментов, на которые стоит обратить внимание:
Если хочется именно чистый Linux, как в моем случае, то сначала нужно проверить, можно ли разблокировать загрузчик на телефоне. Насколько я помню, Op5t разблокируется не сложнее, чем Op3t
Насколько хорошо SoC и платформа в целом поддержаны в mainline Linux или наличие форков под конкретные устройства. Можно и самому доработать, но затратно по ресурсам
Еще есть вариант попробовать сделать в Termux, но того уровня гибкости, который дает полноценная система не получить
Согласен, метод then тут явно выигрывает по чистоте. DelegatedScreenStrategy я привёл скорее для наглядности — чтобы показать сам принцип выбора
Ничего не мешает, с этим просто неудобно работать
необходимо создать список, прокинуть его в compose и di
все еще нужно напрямую изменять список, что я лично для меня не является удобным
навигация доступна не из одного места в приложении, а во многих, другими словами, требуется протаскивать список по многим местам
Лично для меня это вопрос удобства и снижения количества возможных ошибок и проблем
Да, по сути взята архитектура из Cicerone и допилена для использования с Nav3
1) в чем по-вашему выражается сильная связь?
2) чем может помочь path навигация? если это выглядит так, как в примере ниже, то в android от этого очень долго пытались уйти в навигации от гугл и наконец ушли тк типизированная в контексте android подходит гораздо больше
3) чем плох config based router в контексте android разработки?
Тоже реализовывал подобное некоторое время назад, статья есть здесь на habr
Возможно, что будет интересно: https://habr.com/ru/articles/881982/
Например, создаю AuthFeatureViewModel
Скрытый текст
Помещаю ее в скоуп фичи
Скрытый текст
Инициализирую AuthFeatureViewModel
Скрытый текст
AuthFeatureViewModel создается в скоупе фичи. Но есть минус с дублированием кода, потому что этот код
Скрытый текст
Должен находиться в декларации каждого экрана, на который может быть совершен самый первый переход в рамках AuthGraph
Да, изначально пробовал делать без них. Уперся в то, что без ViewModel не получалось понять, в какой момент закрыть скоуп фичи.
Для такого я создаю ViewModel, в скоупе фичи и выполняю действие внутри нее
А вы уже обрабатывали кейс, когда нужно передавать параметры в объект, который живет в рамках скоупа фичи? Это отдельное приключение
Замечание справедливое, поэтому я доработал компонент и обновил статью. Спасибо!
Не, я успел их застать. Дома стоял один из таких телефонов, правда потом заменили на кнопочный, а потом на беспроводной
спасибо!
Насчет более сложный лейаутов пока что не знаю т.к. на данный момент нет идей как и о чем именно можно было бы рассказать