Dev Easy Notes

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

Приложение может состоять из многих модулей. Соответственно в каждом модуле будет определен свой AndroidManifest, в нем будут описываться компоненты, которые используются в данном модуле. Помимо этого вы можете подключать некоторые библиотеки, в которых могут быть свои Activity, Service и т.д.  У этой библиотеки также будет свой AndroidManifest.

К чем я все это веду? Когда вы собираете ваше приложение, компилятор мержит все эти манифесты в один большой манифест. Потому как в конечном архиве(apk) система ожидает увидеть только один манифест. Нужно понимать этот механизм.

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

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

Другими словами, если вы в своей либе создадите манифест, в котором укажете свой Content Provider, он будет запущен до старта приложения. Это дает возможность словить момент запуска приложения и даже получить контекст. При этом не нужно ничего нигде прописывать, система сама создаст Content Provider и дернет метод onCreate. Из этого получаем два вывода. 

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

Вывод номер два. Можно прикрутить функциональность ничего не прописывая в коде. Именно этот механизм и использует LeakCanary. Библиотека просто подсовывает свой Content Provider, тем самым отлавливает момент запуска приложения. Ну а получив доступ к Context, LeakCanary получает доступ практически ко всему приложению. Она навешивает кучу листнеров которые позволяют отлеживать все Acivity, Fragment, Service и т.д.

P.S По этой же схеме работают некоторые библиотеки гугла, вроде Firebase.

❤36👍20🔥2

www.tgoop.com/dev_easy_notes/113

1.68K viewsedited  Jun 3, 2022 at 17:22

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

Приложение может состоять из многих модулей. Соответственно в каждом модуле будет определен свой AndroidManifest, в нем будут описываться компоненты, которые используются в данном модуле. Помимо этого вы можете подключать некоторые библиотеки, в которых могут быть свои Activity, Service и т.д.  У этой библиотеки также будет свой AndroidManifest.

К чем я все это веду? Когда вы собираете ваше приложение, компилятор мержит все эти манифесты в один большой манифест. Потому как в конечном архиве(apk) система ожидает увидеть только один манифест. Нужно понимать этот механизм.

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

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

Другими словами, если вы в своей либе создадите манифест, в котором укажете свой Content Provider, он будет запущен до старта приложения. Это дает возможность словить момент запуска приложения и даже получить контекст. При этом не нужно ничего нигде прописывать, система сама создаст Content Provider и дернет метод onCreate. Из этого получаем два вывода. 

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

Вывод номер два. Можно прикрутить функциональность ничего не прописывая в коде. Именно этот механизм и использует LeakCanary. Библиотека просто подсовывает свой Content Provider, тем самым отлавливает момент запуска приложения. Ну а получив доступ к Context, LeakCanary получает доступ практически ко всему приложению. Она навешивает кучу листнеров которые позволяют отлеживать все Acivity, Fragment, Service и т.д.

P.S По этой же схеме работают некоторые библиотеки гугла, вроде Firebase.

BY Dev Easy Notes