Build что это такое в телефоне

Что такое номер билда?

build number <имя существительное>номер текущего варианта программы <м. р.>номер сборки <м.

Что такое билд в приложении?

Сбо́рка (англ. build) (предметное имя существительное) — подготовленный для использования информационный продукт. Чаще всего сборка — исполняемый файл — двоичный файл, содержащий исполняемый код (машинные инструкции) программы или библиотеки.

Что такое билд в тестировании?

Билд (от англ. to build — сооружать, строить) — конечный результат компиляции программы с уникальным номером версии сборки.

Here's how to find what Android version and build number you have

We have a great set of update guides here at Android Authority that are sure to keep you on the newest Android build. However, they’re only beneficial if you know what version you’re currently running. Lucky for you, this information isn’t all that hard to track down. Here’s how to find out what Android version and build number your device is running.

QUICK ANSWER

You can find your Android version and build number by going to Settings > About phone > Android version.

JUMP TO KEY SECTIONS

Editor’s note: We compiled these instructions using a Google Pixel 7 running Android 13. Remember that some steps and menus may differ slightly depending on your hardware and software.

What is a build number, and what does it mean?

It’s always good to know what software you’re running. Sure, it’s easy to say that you’re running Android 13, but what if you want to know more than that? That’s where Android build numbers come in. A build number is a specific identifier that lets you know what software you’re running as well as when it was updated last. That means your Android build number will change pretty frequently — maybe every month, depending on your device.

What’s the difference between a build number and a version for Android?

This is the part where we could go into some serious scientific taxonomy, explaining phyla, families, and species. I never really liked high school biology, but it’s applicable in this case. We’ll stick to the bottom three levels of the pyramid for this explanation. All Android devices fall into the same family, which we’re defining as Android (iOS would be another family). From there, the Android version number is kind of like a genus — Android 11 devices have their version numbers in common, as do Android 12 devices.

Finally, we come to the build number. The Android build number is the species in this analogy, the most specific piece of information that identifies the software on your phone. While two devices could have the same Android version number, the difference in build numbers could give you a completely different experience if one is more up-to-date than the other.

Ultimately, the Android version number refers to full updates like Android 12 and 13, while the build number gets into the specifics of when your phone was updated and the software version onboard.

Android курс в Технополисе 2022

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

Устройство проекта

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

Build скрипты

Стандартная система сборки Android приложений основана на Gradle (https://gradle.org/) – опенсорнсом инструменте для сборки общего назначения – и плагине для Gradle, который знает, как собирать Android проекты. Вам не нужно устанавливать эти инструменты, потому что система сборки устроена так, что всё необходимое скачивается и устанавливается во время сборки (удобно, но требует подключения к Интернету во время сборки). Однако, если по каким-то причинам, вы не хотите использовать предустановленный дистрибутив Gradle, вы можете указать путь к нему в настройках Android Studio (Use gradle from в разделе Build, Execution, Deployment / Gradle настроек).

Стандартная конфигурация системы сборки включает использование Gradle Wrapper. Для этого в проекте есть специальные файлы:

gradlew и gradlew.bat – это скрипты для запуска Gradle Wrapper для Linux подобных систем и для Windows. Gradle Wrapper является Java приложением и находится в файле gradle-wrapper.jar. Очевидно, что для запуска сборки необходима установленная Java – она входит в комплект установки Android Studio.

Файл gradle-wrapper.properties содержит самые общие параметры запуска Gradle, и, наверно, единственный параметр, который вам может понадобиться менять – это версия Gradle в параметре distributionUrl . Если вы долго работаете над одним проектом, то за время работы может появиться более новая версия Gradle, и тогда, чтобы перейти на неё, вам придется подредактировать gradle-wrapper.properties .

После старта Gradle Wrapper при необходимости скачивает необходимую версию Gradle и запускает его, чтобы тот занялся уже непосредственно сборкой проекта. За сборку проекта отвечают следующие файлы:

Начнем с local.properties – в этом файле определены свойства, значения которых имеют смысл только на вашей машине, на которой вы запускаете сборку. Это, прежде всего, sdk.dir – путь к установленному Android SDK. Файл local.properties должен быть свой у каждого разработчика, который работает над проектом, и его не надо коммитить в общий репозиторий. Если в вашем проекте нет других настроек, зависящих от машины, на которой запускается сборка, то проще определить переменную окружения ANDROID_HOME – тогда файл local.properties вообще не будет нужен.

Файл gradle.properties содержит настройки, которые используется при сборке проекта. В новом проект там обычно определено свойство org.gradle.jvmargs , в котором прописан параметр -Xmx для запуска JVM. Сборка Android приложений требует много памяти, особенно если проект большой (а большим проект может стать очень быстро), поэтому, когда заметите, что сборка стала сильно тормозить, проверьте – не упирается ли она в память, и не надо ли увеличить -Xmx . Впрочем, оптимизация и ускорение сборки Android проектов это отдельная сложная тема, и одним параметром -Xmx вопрос не ограничивается.

Файл settings.gradle обычно определяет структуру проекта. В новом проекте приложения типа Hello World, содержимое этого файла выглядит так:

Здесь указан единственный модуль, из которого состоит проект. Если модулей больше – они перечисляются через запятую: include ‘:app’, ‘:module1’, ‘module2’ .

Файл build.gradle в корне проекта уже содержит какое-то “мясо” – здесь описывается сборка всего проекта на уровне, общем для всех модулей. Файл начинается со следующего блока:

Файл app/build.gradle, который лежит в папке модуля приложения app, описывает сборку этого модуля, а так как этот модуль содержит само приложение, в этом билд скрипте содержится всё самое интересное. Первая его строчка

определяет, что перед нами модуль, содержащий Android приложение, и для его сборки будет использовать Android Gradle плагин. Другой возможный вариант – это com.android.library для библиотечных модулей. Обычно Android проект содержит один модуль приложения и любое количество библиотечных модулей.

Затем идет блок android , в котором определены основные параметры приложения:

applicationId – это ID, по которому приложения идентифицируются в операционной системе Android и в магазинах приложений вроде Google Play. Этот ID мы указывали при создании проекта в Android Studio.

versionName – это версия приложения, как её будут видеть пользователи, например, на странице приложения в Google Play или в системных настройках Android устройства в информации о приложении. Значение versionName может быть любым, но обычно это числа, разделенные точками: 1.0 , 1.1 , 2.0 , 2.0.1 – это традиционная семантическая система нумерации версий. Иногда в versionName кодируют дату релиза приложения: 19.1.22 (22 января 2019 года). Могут присутствовать буквы, например: 5.1-alpha , 19.2.13-debug и пр. Вообще, versionName используется исключительно как текст для отображения пользователям.

versionCode – это тоже версия приложения, но, в отличие от versionName , имеет значение типа int и используется для алгоритмической обработки и в бизнеc-логике приложения. Допустимые значения: положительные целые числа, обязательно возрастающие с каждой версией приложения. Если вы публикуете приложение в магазине приложений, то в каждом следующем обновлении должно быть большее значение versionCode .

Далее идут три похожих свойства: compileSdkVersion, minSdkVersion и targetSdkVersion – это всё про версии Android.

Разные версии Android…

compileSdkVersion определяет версию Android, которая будет использоваться для того, чтобы скомпилировать код приложения. Для каждой версии Android в Android SDK есть свой файл android.jar, содержащий все классы и методы, имеющиеся в этой версии Android. Когда Java код приложения компилируется при помощи javac, в classpath добавляется этот android.jar и таким образом коду приложения становятся доступны все API из этой версии Android. При просмотре Android API Reference обратите внимание – для каждого класса или метода есть указание, в какой версии Android этот класс или метод появился. Например, метод View.setTranslationZ(float) появился в API Level 21:

Если метод появился в API Level 21, это значит, что для того, чтобы использовать его в коде приложения, нужно установить значение compileSdkVersion 21 или выше.

minSdkVersion определяет минимальную версию Android, на которой приложение может быть установлено и запущено. Этот параметр вы указывали при создании приложения в Android Studio. С точки зрения простоты разработки, чем выше minSdkVersion, тем лучше – тогда разработчикам не придется заботиться о том, чтобы приложение правильно работало на старых версиях Android (обычно приложения лучше работают на более новых версиях Android – там меньше багов, меньше технических ограничений, чаще более мощные процессоры с большим объемом памяти и т.п.). Однако, увеличивая minSdkVersion, вы ограничиваете количество устройств, на которых будет работать приложение и уменьшаете его потенциальную аудиторию – а это плохо для бизнеса, в котором используется приложение. Поэтому приходится искать баланс между стоимостью поддeржки старых версий Android и потенциальной выгодой для бизнеса от расширения аудитории.

targetSdkVersion – это версия Android, для которой “предназначено” ваше приложение. Это значит, в общих чертах, что в процессе разработки вы продумывали работу приложения на этой версии Android, тестировали на ней, и гарантируете, что на targetSdkVersion версии Android ваше приложение работает хорошо, без багов – так, как задумывалось. Это нужно для того, чтобы в будущих версиях Android (которые еще не вышли, и про которые мы ничего не можем знать во время разработки приложения) наше приложение продолжало работать так, как мы задумывали, несмотря на то, что технологии могли измениться, поведение операционной системы могло измениться и, вообще говоря, по меркам будущих версий Android, наше сегодняшнее приложение может считаться написанным неправильно. Когда Android запускает приложение со старым targetSdkVesion, он может принять дополнительные меры для того, чтобы приложение работало правильно – запустить его в особом compatibility режиме. Указывая targetSdkVersion, мы фиксируем набор правил и поведение операционной системы, которые действительны для этой версии Android, и таким образом мы можем больше не заботиться о поддержке более новых версий Android. Впрочем, Google может не дать нам расслабиться – иногда в магазине приложений Google Play появляются ограничения на использование старых версий в targetSdkVersion. Например, c 1 авгутста 2018 года в Google Play нельзя публиковать новые приложения с targetSdkVersion меньше 26 (а с 1 ноября 2018 – и обновления старых приложений). Это заставило всех разработчиков оптимизировать их приложения под Android 8.0 (самое сложное – пришлось переписать работу фоновых сервисов).

Build Types

В дефолтном сгенерированном build скрипте есть раздел buildTypes:

В Android проекте есть два стандартных типа сборки: release и debug.

По умолчанию в Android Studio используется тип сборки debug. Эта сборка предназначена для того, чтобы отлаживать её – в ней может делаться меньше оптимизаций, добавляться больше отладочной информации, могут включаться специальные режимы работы, удобные для тестирования, логирование и пр. Debug сборки не предназначены для пользователей, и их нельзя публиковать и распространять через магазины приложений. Внутри buildTypes дефолтного build скрипта блок debug отсутствует – просто потому, что для debug сборки используются все значения по умолчанию.

release сборка, наоборот, предназначена для пользователей. Она максимально оптимизирована, из неё удаляется всё лишнее, её нельзя отлаживать при помощи дебаггера. Кроме того, release сборка подписывается сертификатом разработчика для удостоверения её происхождения и обеспечения целостности (чтобы злоумышленники не могли распространять свои зловреды под видом популярных приложений). Настройки minifyEnabled и proguardFiles относятся к процессу минификации: при сборке релизной версии приложения, её код проходит стадию минификации – лишний неиспользуемый код удаляется, Java имена сокращаются. Это позволяет уменьшить размер кода и немного ускорить его загрузку, но сильно усложняет отладку.

Сборка проекта

После того как вы собрали приложение в Android Studio, в проекте появляется папка app/build (если бы было несколько модулей, то в каждом модуле появилась бы папка build ). В ней содержатся результаты сборки и промежуточные файлы.

APK файл

Собранный APK файл приложения находится в app/build/intermidiates/apk/debug/app-debug.apk (для дебажной сборки) – именно этот файл устанавливается на устройство, когда вы запускаете приложение из Android Studio. Его можно даже открыть и посмотреть его содержимое:

Внутри APK файла можно найти:

• AndroidManifest.xml – манифест приложения, по которому операционная система узнает о структуре приложения.
• classes.dex и classes2.dex – исходный код, скомпилированный в специальны Dalvik byte code и упакованный в DEX (Dalvik EXecutable) файл
• kotlin – так называемые “built-in” котлин классы
• resources.arsc – значения всех ресурсов приложения, упакованные в один файл
• res – папка с более сложными ресурсами, которые хранятся в отдельных файлах (картинки, файлы верстки)
• META-INF – папка со служебной информацией, в первую очередь – с подписями всех файлов.

Все XML файлы, которые можно увидеть внутри APK файла при помощи Android Studio, на самом деле хранятся в оптимизированном бинарном формате, который занимает меньше места и быстрее парсится в рантайме.

Внутри app/build особый интерес представляет папка generated – здесь находятся исходники, которые были автоматически сгенерированы во время сборки приложения. Мы эти исходники не писали, но мы можем их использовать в своем коде, и часто это даже необходимо.

BuildConfig файл

В классе BuildConfig определены константы с информацией о сборке приложения, взятые из build.gradle во время сборки.

Так выглядит BuildConfig для дебажной сборки в app/build/generated/source/buildConfig/debug/ru/ok/technopolis/ :

Константа DEBUG полезна для того, чтобы в коде выполнять разные действия в релизной или дебажной сборке: например, в случае непредвиденной ситуации в дебаге можно бросить исключение, чтобы обнаружить эту ситуацию как можно раньше на этапе разработки, а в релизной версии бросать исключение нельзя (чтобы не расстраивать пользователя) – лучше тихо отправить логи в сервис сбора аналитики:

В BuildConfog можно добавлять свои собственные константы. Для этого нужно добавить определение константы в build.gradle , и они будут добавлены статическими полями в класс BuildGradle во время сборки:

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

Логирование

В Android есть единый системный лог, в который попадают сообщения от всех компонентов системы и от всех приложений. Инструмент для просмотра логов называется Logcat – он встроен в Android Studio, и для него есть одноименное окно, в котором можно просматривать логи:

Logcat работает в режиме реального времени – вы можете видеть логи, которые печатаются прямо сейчас или были напечатаны недавно (благодаря небольшому кольцевому буферу, который есть в операционной системе Android), но вы не можете поднять логи за вчера – они никуда не записываются. Поэтому логи в Android – это в первую очередь инструмент отладки, который используется в процессе разработки приложения, а не журнал, по которому можно восстановить историю событий за прошедшее время.

Приложения могут писать в логи при помощи стандартного класса android.util.Log , в котором есть набор методов для печати сообщений в лог с разным приоритетом. Вот базовый список методов в порядке убывания приоритета:

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

При выполнении этого кода в момент старта activity HelloWorldActivity в лог будет напечатано такое сообщение:

Оно содержит точное время, ID юзера ( 28880 ), процесса ( 28880 ) и приложения ( ru.ok.technopolis ), из которого пришел лог, метка приоритета D , тэг Hello и собственно сообщение. В окне Logcat в Android Studio можно осуществлять поиск по логам, фильтровать по произвольной подстроке и по приоритету и таким образом видеть только те логи, которые вас интересуют в данный момент.

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

Обратите внимание на то, как метод логирования вызывается под условием:

Использование константы log необходимо по двум причинам:

• Можно включить или выключить все логи сразу, изменив одну константу.
• В выключенном состоянии выражение if (log) эквивалентно if (false) , и Java компилятор полностью вырежет весь код, следующий за условием. В релизной версии, в которой обычно логи выключены, это то, что нам нужно – избавиться от лишнего неиспользуемого кода. Для того чтобы это работало, константа log должна быть определена именно константой.

Удобнее всего определять константу log при помощи BuildConfig . Для этого надо написать следующее в build.gradle приложения:

и в коде использовать BuildConfig.log – это будет одна константа на все приложение:

Падение приложения

Когда при выполнении кода приложения выбрасывается исключение, которое никто не ловит, приложение падает – выполнение кода прекращается, виртуальная машина останавливается и процесс приложения завершается. Это называется крэш (crash). Пользователь при этом видит системное сообщение о том, что приложение упало:

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

Для примера попробуем изменить код HelloWorldActivity так, чтобы он упал: при вызове setContentView из метода onCreate замените идентификатор файла верстки R.layout.activity_hello_world на идентификатор строки R.string.hello_world :

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

Первое, что мы видим – это строка со словами FATAL EXCEPTION и идентификатором упавшего приложения. Так (почти) всегда начинается сообщение о падении приложения, и если вам надо быстро найти в логе крэш, то проще всего искать его по этим словам.

Затем идет сообщение о непойманном исключении со стэк трейсом – то, что позволит нам найти причину падения. Обычно в стек трейсе можно найти ссылки на код приложения, который привел к ошибке, и в первую очередь нам надо их найти по имени Java пакета, который мы используем в нашем приложении ( ru.ok.technopolis ). Часто стек трейс состоит из нескольких частей, каждая из которых начинается со слов Caused by – это говорит о том, что исключение несколько раз ловилось в различных местах в коде, но не было обработано, а было обернуто в новый тип исключения и проброшено дальше. Вы быстро научитесь ориентироваться в стек трейсах, но если поиск нужной строчки вызывает затруднения, то можно действовать так:

• найдите последнюю часть стек трейса, начинающуюся со слов Сaused by
• начинайте просматривать трейс сверху вниз
• ищите первую строчку, принадлежащую вашему коду.

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

Это то самое место, в котором мы сделали неправильный вызов setContentView .

Твики build.prop для Android, которые действительно работают

Львиная доля системных параметров Android, скрытых от глаз пользователя, хранится в единственном файле под названием build.prop. Грамотное изменение настроек поможет вдохнуть вторую жизнь в гаджет: улучшить автономность и производительность, оптимизировать интерфейс. В статье мы покажем, как удобно редактировать build.prop, и приведём примеры полезных твиков, а также тех, которые кочуют из статьи в статью на разных ресурсах, но на самом деле не работают.

Что даёт редактирование файла build.prop?

Файл build.prop функционирует следующим образом: при запуске смартфона из него считывается содержимое, тем или иным образом влияющее на логику работы кода операционной системы. Среди таких спрятанных от пользователя настроек есть как глубоко системные, которые лучше не трогать, так и те, которые могут быть безболезненно изменены. Например, добавив несколько строк в build.prop, вы можете ускорить загрузку гаджета, убрать задержку при входящем вызове или включить автоповорот дисплея на экране блокировки. Как это сделать, мы сейчас расскажем.

Как редактировать build.prop?

Всё, что вам потребуется для внесения изменений — редактор текстовых файлов и права суперпользователя. Узнать, как получить root-доступ, можно на нашем форуме в разделе прошивок для Android в теме, посвящённой вашему смартфону или планшету. Для непосредственных изменений в файле можно пользоваться обычным текстовым редактором — для этого придётся самостоятельно найти файл по пути /system/build.prop. Но намного удобнее вносить изменения с помощью специализированной программы, например, BuildProp Editor.

Перед тем как приступить к экспериментам, необходимо обязательно сделать резервную копию файла. BuildProp Editor сохраняет бэкап оригинала автоматически при первом запуске. Если же вы решите пользоваться обычным текстовым редактором, то не забудьте сделать копию вручную. Если что-то вдруг пойдёт не так, то вам будет достаточно заменить «испорченный» build.prop резервной копией, чтобы вернуть всё на свои места.

Улучшение интерфейса

Для удобства мы разбили твики на несколько категорий. Первая — улучшение интерфейса. Такие твики наиболее наглядны, поскольку они нередко влияют не только на параметры системы, но и на её внешний вид.

Мгновенный звук вызова. В зависимости от модели смартфона и установленной прошивки при поступлении звонка гаджет может потратить какое-то время на проверку соединения, прежде чем заиграет мелодия. Для пользователя это выглядит следующим образом: сначала у аппарата просто включается дисплей, и только через секунду с небольшим отображается сам звонок. Исправить такое поведение можно внесением в build.prop двух строк:

После перезагрузки аппарата все звонки будут поступать мгновенно.

Автоповорот экрана блокировки. За исключением планшетов, практически ни одно Android-устройство не даёт возможность свободно поворачивать экран блокировки при повороте смартфона. Да, эта функция бывает нужна редко, но если гаджет установлен горизонтально в автомобильном держателе, то попытка ввода пароля или графического ключа превращается в настоящую эквилибристику. Всё, что нужно, чтобы избежать акробатических трюков — дописать в build.prop строки

Что из этого получится — можете увидеть на скриншоте.

Улучшение производительности

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

Ускорение загрузки. Современные смартфоны нередко загружаются едва ли не дольше, чем обычные ПК. Немного поколдовав над настройками в build.prop, можно с лёгкостью увеличить скорость загрузки гаджета в полтора-два раза! В этом помогут следующие настройки:

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

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

Отключение лога уменьшит количество дисковых операций, что положительно скажется на быстродействии внутренней памяти смартфона. Правда, разница будет заметна разве что на гаджетах с медленными типами памяти: в нашем случае скорость последовательной записи возросла на 2 МБ/с.

alt=»Твики build.prop для Android» width=»270″ height=»480″ />

Ускорение сети. Этот твик увеличивает размеры TCP-буферов, что поможет увеличить скорость медленного интернет-соединения, особенно при использовании мобильных сетей. Ну а прописывание DNS-серверов Google в некоторых случаях позволяет снизить время пинга.

net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960

net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960

net.rmnet0.dns1=8.8.8.8

net.rmnet0.dns2=8.8.4.4

net.dns1=8.8.8.8

net.dns2=8.8.4.4

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

Скорость передачи данных со стандартными настройками Скорость передачи данных после редактирования build.prop

Увеличение автономности

К сожалению, чудес не бывает — двукратного увеличения автономности достичь не удастся никакими твиками. Но добавить лишние 30-60 минут к времени работы гаджета вполне возможно.

Увеличение интервалов сканирования Wi-Fi. По умолчанию Android сканирует окружающие сети Wi-Fi каждые 20-90 секунд. Причём делает это даже тогда, когда Wi-Fi выключен, но разрешён фоновый поиск сетей для увеличения точности определения местоположения. Чтобы расширить данный интервал, необходимо добавить в файл build.prop строку:

Здесь число 200 и является интервалом сканирования сетей в секундах.

Экономия заряда на LineageOS. Небольшой твик, обеспечивающий более эффективное управление спящим режимом при использовании CyanogenMod или LineageOS на смартфонах с чипсетами Qualcomm:

Ещё больше полезных твиков вы можете найти на форуме 4PDA:

Бесполезные твики, которые ничего не улучшают

Помимо действительно работающих твиков, приведённых в этой статье и в теме на форуме, существует немало таких, которые широко разошлись по Сети, но на самом деле не оказывают никакого влияния на работу системы. Соответствующее исследование провёл один из пользователей ресурса xda. Он проанализировал исходный код AOSP и CyanogenMod и выяснил, что множество популярных твиков просто не упомянуты в исходном коде Android. Среди них есть самые разные записи.

Твики, не экономящие заряд:

ro.ril.disable.power.collapse

ro.mot.eri.losalert.delay

ro.config.hw_fast_dormancy

ro.config.hw_power_saving

Твики, не ускоряющие работу:

windowsmgr.max_events_per_sec

persist.cust.tel.eons

ro.max.fling_velocity

ro.min.fling_velocity
debug.performance.tuning

video.accelerate.hw

Другие бесполезные твики. Они предназначены для отключения проверки байт-кода Dalvik и запрета выгрузки лончера из оперативной памяти. Когда-то они действительно работали, но совершенно не актуальны для современных версий Android из-за изменения внутренней архитектуры ОС: