Русские Блоги
Один, механизм кеширования Android
Кэш Android разделен на кеш памяти и файловый кеш (дисковый кеш). В первые дни, до того, как стали популярными основные фреймворки кэширования изображений, наиболее часто используемыми методами кэширования памяти были SoftReference и WeakReference.Например, большинство методов использования: HashMap > imageCache; форма. Начиная с Android 2.3 (уровень 9), сборщик мусора более склонен к повторному использованию объектов SoftReference или WeakReference, что делает SoftReference и WeakReference менее практичными и эффективными. В то же время после Android 3.0 (уровень 11) Bitmap данных изображения помещается в область кучи памяти, а память в области кучи управляется сборщиком мусора, и разработчику не нужно освобождать ресурсы изображения, но это также делает Выпуск данных изображения непредсказуем, что увеличивает вероятность OOM. Поэтому после Android 3.1 в Android появился класс кэша памяти LruCache, и на объекты в LruCache имеются сильные ссылки.
Во-вторых, рабочий механизм вторичного кеша
Так называемый кеш второго уровня на самом деле не сложен.Когда стороне Android требуется получить данные, например получить изображения из сети, мы сначала ищем в памяти (поиск по ключу), а затем ищем файл на диске или sqlite, если в памяти ничего нет. Он недоступен на диске, пока не будет получен через сеть; когда данные из сети получены, они сначала кэшируются в памяти (кеш первого уровня) в виде пар ключ-значение, и в то же время кешируются в файле или sqlite (кеш второго уровня). Примечание. Кэш памяти вызовет утечку памяти в виде кучи. Все кеши уровня 1 обычно должны строго контролировать размер кеша, обычно контролируемый на 1/4 системной памяти.
Три, автономный кеш
Автономное кэширование предназначено для локального сохранения данных, полученных с сервера, когда сеть разблокирована, и прямого чтения данных из локального файла, когда сеть отключена. Суть в том, чтобы контролировать хранение и чтение файлов.
Наши приложения обычно генерируют следующие типы данных:
Все пути к данным в приложении:
/data/data/com.xxx.xxx/cache-in-app cache (Примечание: соответствующий метод getCacheDir ())
/data/data/com.xxx.xxx/databases-in-app база данных
/data/data/com.xxx.xxx/shared_prefs-in-app файл конфигурации
/data/data/com.xxx.xxx/files-In-app files (Примечание: соответствующий метод getFilesDir ())
Файл SD-карты (разработан индивидуально)
Независимо от того, внутренняя это или внешняя SD-карта, способ получения пути один и тот же:
Получите корневой каталог SD-карты: Environment.getExternalStorageDirectory (). GetAbsolutePath ();
Путь к внешнему кэшу: /mnt/sdcard/android/data/com.xxx.xxx/cache Общее хранилище данных кеша (Примечание: получено с помощью getExternalCacheDir ())
Путь к внешнему файлу: /mnt/sdcard/android/data/com.xxx.xxx/files Хранить долгоживущие данные (Примечание: полученные с помощью getExternalFilesDir (тип String), тип специфичен Тип, может быть любым из следующих
Environment.DIRECTORY_MUSIC, Environment.DIRECTORY_PODCASTS, Environment.DIRECTORY_RINGTONES, Environment.DIRECTORY_ALARMS, Environment.DIRECTORY_NOTIFICATIONS, Environment.DIRECTORY_PICTURES, or Environment.DIRECTORY_MOVIES. ）
В-четвертых, обычно используемое хранилище Android:
Пять основных методов хранения данных на платформе Android:
1 Используйте SharedPreferences для хранения данных
2 Данные для хранения файлов
3 База данных SQLite для хранения данных
4 Используйте ContentProvider для хранения данных
5 Данные сетевого хранилища
Следующее знакомит с использованием первых двух, база данных может использовать библиотеку более удобно, например: greenDao; другие, но не слишком много введения. В основном ввести кеш.
(1) Подробное объяснение SharedPreferences
Шаги по использованию SharedPreferences для сохранения пар ключ-значение обычно следующие:
Используйте метод getSharedPreferences класса Activity, чтобы получить объект SharedPreferences, укажите имя файла и права доступа
Получите объект SharedPreferences.Editor и используйте метод putXxx объекта для сохранения пары «ключ-значение».
Сохранение (отправка) пар «ключ-значение» с помощью метода фиксации SharedPreferences.Editor.
(1) Два способа получить SharedPreferences:
1 Вызовите метод getSharedPreferences () объекта Context
2 Вызовите метод getPreferences () объекта Activity.
(2) Разница между двумя методами:
Объект SharedPreferences, полученный путем вызова метода getSharedPreferences () объекта Context, может использоваться другими приложениями в том же приложении.Компонентыобщий.
Объект SharedPreferences, полученный путем вызова метода getPreferences () объекта Activity, может использоваться только в Activity.
(3) Четыре режима работы SharedPreferences:
Context.MODE_PRIVATE: это режим работы по умолчанию, что означает, что файл является личными данными и может быть доступен только самому приложению. В этом режиме записанное содержимое будет перезаписывать содержимое исходного файла.
Context.MODE_APPEND: режим проверит, существует ли файл, добавит содержимое в файл, если он существует, или создаст новый файл.
Context.MODE_WORLD_READABLE и Context.MODE_WORLD_WRITEABLE используются, чтобы контролировать, есть ли у других приложений разрешение на чтение и запись файла.
MODE_WORLD_READABLE: указывает, что текущий файл может быть прочитан другими приложениями.
MODE_WORLD_WRITEABLE: указывает, что текущий файл может быть записан другими приложениями.
(4) Сохраните данные в SharedPreferences:
Или следующее письмо также может быть
(5) Получите данные из SharedPreferences:
(2) Подробное описание хранилища файлов (Файл)
(1) Методы хранения файлов, предоставляемые Context (openFileOutput, openFileInput)
(I) Сохраните фрагмент текстового содержимого в файл:
Примечание. По умолчанию файл будет храниться в / data / data / package / files;
Подобно хранению данных в файле, класс Context также предоставляетopenFileInput()Метод чтения данных из файла.
Метод openFileInput () получает только один параметр, то есть имя файла для чтения, и система автоматически перейдет в каталог / data / data /
/ files /, чтобы загрузить этот файл и вернуть объект FileInputStream.
(II) Покажите, как читать текстовые данные из файла:
(III) Четыре режима сохранения файлов.
(2) Внутренняя память: файл общих операций потока ввода-вывода
getFilesDir()Получите внутреннее хранилище вашего приложения, которое эквивалентно корневому каталогу вашего приложения во внутреннем хранилище.
После установки приложения / data / data / packagename будет сгенерирован в корневом каталоге Android, и текущему приложению не требуются разрешения на чтение и запись для чтения.
нота:
Некоторые разработчики, возможно, видели корневой каталог приложения / data / user / 0 / packagename, вот объяснение, версия Android 4.2 добавляет функцию входа в систему для разных пользователей на одном устройстве. (По причинам, связанным с патентом, эта функция ограничена планшетами, мобильные телефоны не поддерживают эту функцию), поэтому, чтобы различать настройки и сохраненные данные разных пользователей в одном приложении, добавляется путь этой серии, который указывает на / data / data / packagename
нота:
Этот каталог можно просмотреть только с правами root и будет удален при удалении приложения.
Очистка данных в деталях приложения приведет к удалению всех данных под именем пакета и всего каталога / Android / data / packagename во внутреннем хранилище и на внешней SD-карте.
Очистка кеша в деталях приложения приведет к удалению всех данных в каталоге packagename / cache и всего каталога / Android / data / packagename / cache во внутренней памяти и на внешней памяти SD-карты.
Если вы хотите создать файл, выполните следующие действия.
Android также предоставляет нам простой способopenFileOutput()`Для чтения и записи файлов во внутренней памяти ниже приведен пример записи текста в файл: (см. Выше)
Некоторые другие операции с внутренней памятью:
A. Перечислите все созданные файлы, это может быть непросто, Context Есть такой способ.
Б. Чтобы удалить файл, если вы можете его создать, вы должны иметь возможность удалить его. Конечно, он также предоставляет интерфейс для удаления файлов. Это также очень просто. Вам нужно только указать имя файла.
C. Чтобы создать каталог, вам необходимо передать имя каталога, и он возвращает файловый объект, используя путь к операции
Обобщая файловые операции, мы можем получить следующие три характеристики:
(3) Внешнее хранилище: ввод-вывод (чтение и запись файлов на SD-карте)
Путь хранения собственного ПЗУ телефона
1. Метод getExternalCacheDir () для получения пути к каталогу / Android / data / packagename / cache на встроенной карте памяти, разрешения на чтение и запись не требуются после версии 4.4 и будут удалены по мере удаления приложения.
2. Метод getExternalFilesDir () получает путь к каталогу / Android / data / packagename / files на встроенной карте памяти. После версии 4.4 разрешения на чтение и запись не требуются и будут удалены по мере удаления приложения. Если параметр метода имеет значение «null», вложенная папка не указана. Если указано, создается вложенная папка для сохранения файла. Созданный файл может быть прочитан другими приложениями, если у него есть разрешения на чтение и запись. Если вы хотите сохранить его частным, используйте внутреннее хранилище.
3. Метод Environment.getExternalStorageDirectory () получает корневой каталог каталога встроенного хранилища. Требуются разрешения на чтение и запись, которые не будут удалены при удалении приложения.
4. Метод Environment.getExternalStoragePublicDirectory () получает общедоступный каталог с файлом определенного типа по корневому пути каталога встроенного хранилища. Требуются разрешения на чтение и запись, которые не будут удалены при удалении приложения.
5. Обратите внимание, что разрешения на чтение и запись для пути / Android / data / packagenaem / во встроенном хранилище различаются и требуют разных разрешений, поэтому при разработке всегда следует объявлять разрешения на чтение и запись.
Этапы чтения и записи выполняются следующим образом:
1. Вызовите метод getExternalStorageState () среды Environment, чтобы определить, вставлена ли SD-карта в телефон и есть ли у приложения разрешение на чтение и запись на SD-карту. Следующий код вернет истину.
2. Вызовите метод Environment.getExternalStorageDirectory (), чтобы получить внешнее хранилище, которое является каталогом SD-карты, или используйте каталог «/ mnt / sdcard /».
3. Используйте поток ввода-вывода для работы с файлами на SD-карте.
Примечание. В мобильный телефон должна быть вставлена SD-карта. Для симулятора вы можете создать виртуальную карту памяти с помощью команды mksdcard.
Разрешение на чтение и запись SD-карты должно быть настроено в AndroidManifest.xml.
(I) Функция операции записи файла
II) Функция чтения файла
Пять, обобщены некоторые коды использования:
Общее хранилище:
Небольшое тело данных, параметр, значение (хранится в shared_prefs)
сетевые данные json (данные такого типа обычно не большие, хранятся в файле (.txt и т. д.))
картинки, музыка, видео (рекомендуется хранить большие данные на SD-карте, изображения (кадры с кадрами))
Стратегия кеширования в приложении
Когда заходит разговор о кешировании складывается парадоксальная ситуация. С одной стороны все понимают важность и нужность кеширования в архитектуре приложений. С другой стороны мало кто может внятно объяснить что и как надо кешировать.
Обычно люди сходу начинают предлагать готовые реализации кеша, вроде memcached или HTTP-кеша, но это лишь ответ на вопрос где кешировать.
Кеширование – одна из многих тем, наряду с безопасностью и логированием, о которых знают и говорят все, но мало кто может это сделать правильно.
Зачем нужен кеш
Кеш приближает данные к месту их использования. В современном мире, состоящим на 98% из интернета, данные обычно лежат очень далеко от пользователя. На всем пути от хранилища к пользователю есть кеши, которые служат только одной цели – чтобы пользователь как можно быстрее получил свои данные.
Если рассмотреть внимательнее, то видно, что драгоценное время тратится на обработку данных в поставщике и передачу данных от поставщика клиенту, время обработки данных на клиенте тут не учитываем.
При наличии высоких нагрузок кеширование просто необходимо. Оно позволяет обслуживать больше клиентов, с теми же ресурсами, потому что поставщики данных больше отдыхают. Но даже при невысоких нагрузках кеширование положительно влияет на отзывчивость приложения.
Кеш нельзя просто включить
Одно из основных заблуждений насчет кеширования заключается в том, что многие думают что кеш можно просто включить.
На заре своей карьеры программиста я один раз просто так включил кеширование, буквально через час пришлось его выключить. Тогда я нарвался на основную проблему при кешировании – устаревание данных. Пользователь после изменения данных не видел результата 15 минут.
Очень важно понимать что и как вы собираетесь кешировать, чтобы не нарушать логику работы приложения. И первый вопрос, на который вам необходимо ответить – насколько устаревшие данные можно отдавать клиенту. Естественно можно сделать свой кеш для каждого клиента, это упростит решение вопроса об актуальности данных, но принесет много других проблем.
Типы кеширования
Наверное можно придумать и другие типы кешей, но я не встречал.
Устаревание и когерентность кеша
Объем кеша всегда ограничен. Зачастую он меньше объема данных, которые в этот кеш можно положить. Поэтому элементы, помещенные в кеш, рано или поздно будут вытеснены. Современные фреймворки для кеширования позволяют очень гибко управлять устареванием, учитывая приоритеты, время устаревания, объемы данных итд.
Если одни и те же данные попадают в разные кеши, то возникает проблема когерентности кеша. Например одни и те же данные используются для формирования разных страниц и кешируются страницы. Страницы сформированные позже будут содержать обновленные данные, а страницы, закешированные раньше, будут содержать устаревшие данные. Таким образом будет нарушена согласованность поведения.
Простой способ поддержания когерентности – принудительное устаревание (сброс) кеша при изменении данных. Поэтому увеличение памяти для кеша, чтобы он меньше устаревал, не всегда хорошая идея.
Эффективность кеша
Основной параметр, который характеризует систему кеширования – это процент попаданий запросов в кеш. Этот параметр довольно легко измерить, чтобы понять насколько ваша система кеширования эффективна.
Частые сбросы кеша, кеширование редко запрашиваемых данных, недостаточный объем кеша – все это ведет к пустой трате оперативной (обычно) памяти, не повышая эффективность работы.
Иногда данные меняются настолько часто и непредсказуемо, что кеширование не даст эффекта, процент попаданий будет близок к нулю. Но обычно данные считываются гораздо чаще, чем записываются, поэтому кеши эффективны.
Применение разных типов кеширования
Ленивый кеш
Это самый простой вид кеширования, но его нужно использовать осторожно, так как отдает устаревшие данные. Можно при каждой записи сбрасывать ленивый кеш, чтобы поддерживать актуальность данных, но тогда затраты на реализацию будут сравнимы с более сложными типами кеширования.
Такой тип кеширования можно использовать для данных, которые почти никогда не меняются. Другой вариант использования – делать ленивый кеш с небольшим временем устаревания для стабильной работы при всплесках нагрузки.
Такой тип кеширования позволит быстрее всех дать ответ.
Синхронизированный кеш
Это самый полезный тип кеширования, так как отдает свежие данные и позволяет реализовать многоуровневый кеш.
Такой тип кеширования встроен в протокол HTTP. Сервер отдает метку изменения, а клиент кеширует у тебя результат и в последующем запросе передает эту метку. Сервер может дать ответ, что состояние не изменилось и можно использовать кешированный на клиенте объект. Сервер в свою очередь, получив метку может переспросить у хранилища были ли изменения или нет.
Этот тип кеширования не избавляет от накладных расходов на общение между системами. Поэтому часто дополняется другими типами кеширования, чтобы ускорить работу.
Кеш сквозной записи
Если есть система распределенного кеширования (memcached, Windows Sever App Fabric, Azure Cache), то можно использовать кеш сквозной записи. Рукопашная реализация синхронизации кешей между узлами сама по себе отдельный большой проект, потому не стоит заниматься ей в рамках разработки приложения.
Не стоит пытаться кешировать все в синхронизированном кеше, иначе большая часть кода приложения будет заниматься перестройкой кеша.
Также не стоит забывать что системы распределенного кеширования также требуют общения между системами, что может сказываться на быстродействии.
Что еще нужно учитывать в стратегии кеширования
Выбирайте правильную гранулярность кешируемых данных. Например кеширование данных для каждого пользователя скорее всего будет неэффективно при большом количестве пользователей. Если кешировать данные для всех пользователей разом, то возникнут проблемы с устареванием данных и когерентностью кеша.
Кешируйте данные как можно позже, непосредственно перед отдачей во внешнюю систему. Кешировать данные, полученные извне, необходимо только в случае проблем с производительностью на этом этапе. Внешние хранилища, такие как СУБД и файловые системы, сами реализуют кеширование, поэтому обычно нет смысла кешировать результаты запросов.
Не нужно городить свои велосипеды для кеширования в приложениях, обычно уже есть готовые инструменты и надо уметь ими пользоваться.
Кэшируем пагинацию в Android
Наверняка каждый Android разработчик работал со списками, используя RecyclerView. А также многие успели посмотреть как организовать пагинацию в списке, используя Paging Library из Android Architecture Components.
Все просто: устанавливаем PositionalDataSource, задаем конфиги, создаем PagedList и скармливаем все это вместе с адаптером и DiffUtilCallback нашему RecyclerView.
Но что если у нас несколько источников данных? Например, мы хотим иметь кэш в Room и получать данные из сети.
Кейс получается довольно кастомный и в интернете не так уж много информации на эту тему. Я постараюсь это исправить и показать как можно решить такой кейс.
Если вы все еще не знакомы с реализацией пагинации с одним источником данных, то советую перед чтением статьи ознакомиться с этим.
Как бы выглядело решение без пагинации:
Такая удобная штука как пагинация, которая упрощает жизнь пользователям, тут нам ее усложняет. Давайте попробуем представить какие проблемы могут возникнуть при реализации пагинируемого списка с несколькими источниками данных.
Алгоритм примерно следующий:
Из особенностей такого подхода можно заметить, что для отображения списка в первую очередь опрашивается кэш, и сигналом загрузки новых данных является конец кэша.
В Google задумались над этим и создали решение, которое идет из коробки PagingLibrary — BoundaryCallback.
BoundaryCallback сообщает когда локальный источник данных “заканчивается” и уведомляет об этом репозиторий для загрузки новых данных.
На официальном сайте Android Dev есть ссылка на репозиторий с примером проекта, использующего список с пагинацией с двумя источниками данных: Network (Retrofit 2) + Database (Room). Для того, чтобы лучше понять как работает такая система попробуем разобрать этот пример, немного его упростим.
Начнем со слоя data. Создадим два DataSource.
В этом интерфейсе описаны запросы к API Reddit и классы модели (ListingResponse, ListingData, RedditChildrenResponse), в объекты которых будут сворачиваться ответы API.
И сразу сделаем модель для Retrofit и Room
Класс RedditDb.kt, который будет наследовать RoomDatabase.
Помним, что создавать класс RoomDatabase каждый раз для выполнения запроса к БД очень затратно, поэтому в реальном кейсе создавайте его единожды за все время жизни приложения!
И класс Dao с запросами к БД RedditPostDao.kt
Вы наверное заметили, что метод получения записей postsBySubreddit возвращает
DataSource.Factory. Это необходимо для создания нашего PagedList, используя
LivePagedListBuilder, в фоновом потоке. Подробнее об этом вы можете почитать в
уроке.
Отлично, слой data готов. Переходим к слою бизнес логики.Для реализации паттерна “Репозиторий” принято создавать интерфейс репозитория отдельно от его реализации. Поэтому создадим интерфейс RedditPostRepository.kt
И сразу вопрос — что за Listing? Это дата класс, необходимый для отображения списка.
Создаем реализацию репозитория MainRepository.kt
Давайте посмотрим что происходит в нашем репозитории.
Создаем инстансы наших датасорсов и интерфейсы доступа к данным. Для базы данных:
RoomDatabase и Dao, для сети: Retrofit и интерфейс апи.
Далее реализуем обязательный метод репозитория
который настраивает пагинацию:
Реализуем вспомогательный метод
для записи ответа сети в БД. Он будет использоваться, когда нужно будет обновить список или записать новую порцию данных.
Реализуем вспомогательный метод
для тригера обновления данных. Тут все довольно просто: получаем данные с сервера, чистим БД, записываем новые данные в БД.
С репозиторием разобрались. Теперь давайте взглянем поближе на SubredditBoundaryCallback.
В классе, который наследует BoundaryCallback есть несколько обязательных методов:
Метод вызывается, когда БД пуста, здесь мы должны выполнить запрос на сервер для получения первой страницы.
Метод вызывается, когда “итератор” дошел до “дна” БД, здесь мы должны выполнить запрос на сервер для получения следующей страницы, передав ключ, с помощью которого сервер выдаст данные, следующие сразу за последней записью локального стора.
Метод вызывается, когда “итератор” дошел до первого элемента нашего стора. Для реализации нашего кейса можем проигнорировать реализацию этого метода.
Дописываем колбэк для получения данных и передачи их дальше
Дописываем метод записи полученных данных в БД
Что за хэлпер PagingRequestHelper? Это ЗДОРОВЕННЫЙ класс, который нам любезно предоставил Google и предлагает вынести его в библиотеку, но мы просто скопируем его в пакет слоя логики.
Со слоем бизнес логики закончили, можем переходить к реализации представления.
В слое представления у нас новая MVVM от Google на ViewModel и LiveData.
В методе onCreate инициализируем ViewModel, адаптер списка, подписываемся на изменение названия подписки и вызываем через модель запуск работы репозитория.
Если вы не знакомы с механизмами LiveData и ViewModel, то рекомендую ознакомиться с уроками.
В модели реализуем методы, которые будут дергать методы репозитория: retry и refesh.
Адаптер списка будет наследовать PagedListAdapter. Тут все также как и работе с пагинацией и одним источником данных.
И все те же ViewHolder ы для отображения записи и итема состояния загрузки данных из сети.
Если мы запустим приложение, то можем увидеть прогресс бар, а затем и данные с Reddit по запросу androiddev. Если отключим сеть и долистаем до конца нашего списка, то будет сообщение об ошибке и предложение попытаться загрузить данные снова.
Все работает, супер!
И мой репозиторий, где я постарался немного упростить пример от Google.
На этом все. Если вы знаете другие способы как “закэшировать” пагинацию, то обязательно напишите в комменты.
How to clear gradle cache?
Is there a better explanation for why my Android Studio is taking forever to run the gradle assemble task upon first time loading the application?
Do I also have to clear the intellij cache too?
11 Answers 11
Gradle cache is located at
You can browse to these directory and manually delete it or run
on UNIX system. Run this command will also force to download dependencies.
UPDATE
NOTE: Android Studio’s File > Invalidate Caches / Restart doesn’t clear the Android build cache, so you’ll have to clean it separately.
UPDATE 2
This article Put your Android Studio on a diet gives more details on Android Studio caches
Daemon on MS Windows If you’re on Windows, you’ll need to kill the daemon before it allows you to clear those directories. See Kill all Gradle Daemons Regardless Version? for more info.
UPDATE
cleanBuildCache no longer works.
Android Gradle plugin now utilizes Gradle cache feature
https://guides.gradle.org/using-build-cache/
Clean the cache directory to avoid any hits from previous builds
Other digressions: see here (including edits).
=== OBSOLETE INFO ===
Newest solution using Gradle task:
Available via Android plugin for Gradle, revision 2.3.0 (February 2017)
Background
Build cache
Stores certain outputs that the Android plugin generates when building your project (such as unpackaged AARs and pre-dexed remote dependencies). Your clean builds are much faster while using the cache because the build system can simply reuse those cached files during subsequent builds, instead of recreating them. Projects using Android plugin 2.3.0 and higher use the build cache by default. To learn more, read Improve Build Speed with Build Cache.
NOTE: The cleanBuildCache task is not available if you disable the build cache.
USAGE
Android Studio / IntelliJ:
NOTE: gradle / gradlew are system specific files containing scripts. Please see the related system info how to execute the scripts:
Take care with gradle daemon, you have to stop it before clear and re-run gradle.
Run again you compilation
The gradle daemon also creates a many large text files of every single build log. They are stored here:
«X.X» is the gradle version in use, like «4.4», and «XXXX» are just random numbers, like «1234».
The total size can grow to several hundred MB in just a few months. There is no way to disable the logging, and the files are not automatically deleted and they do not really need to be retained.
But you can create a small gradle task to automatically delete them, and free up lots of disk space:
Add this to your app/build.gradle :
Note that a Gradle Sync or any Gradle Build will trigger the file deletions.
A better way would be to automatically move the files to the Trash/Recycle Bin, or at least copy them to a Trash folder first. But I don’t know how to do that.
there seems to be incorrect info posted here. some people report on how to clear the Android builder cache (with task cleanBuildCache ) but do not seem to realize that said cache is independent of Gradle’s build cache, AFAIK.
my understanding is that Android’s cache predates (and inspired) Gradle’s, but i could be wrong. whether the Android builder will be/was updated to use Gradle’s cache and retire its own, i do not know.
EDIT: the Android builder cache is obsolete and has been eliminated. the Android Gradle plugin now uses Gradle’s build cache instead. to control this cache you must now interact with Gradle’s generic cache infrastructure.
TIP: search for Gradle’s cache help online without mentioning the keyword ‘android’ to get help for the currently relevant cache.
surprisingly, i have a cleanBuildCache gradle task and a /.android/build-cache/3.4.2/ directory, both hinting the existence of an Android builder cache.
i execute cleanBuildCache and the 3.4.2/ directory is gone. next i do another clean build :
conclusions:
next, i disable the Gradle cache by removing org.gradle.caching=true from gradle.properties and i try a couple of clean build :
more conclusions:
EDIT 3: user tir38 confirmed that the Android builder cache is obsolete and has been eliminated with this find. tir38 also created this issue. thanks!