Что такое фреймворк андроида

Google Services Framework — что это за программа и нужна ли она на телефоне?

Google Services Framework — системное приложение, которое ускоряет/оптимизирует работу программ Android с данными на смартфоне.

Также нашел инфу — служба Google Services Framework отвечает за управление множеством вариативных коммуникаций с Гуглом, в том числе облачными сообщениями.

Кроме этого данная программа необходима для нормальной работы:

1. Google Cloud Messaging — оповещения в приложениях.
2. Google Play Store — магазин для покупки приложений, медиа-файлов, потокового контента.
3. Учетная запись Google — собственно одно из главного на смартфоне Андроид.
4. Gmail — популярная почта от Гугла.
5. Установка/обновление программ.

Можно ли удалить?

Прога имеет важное значение в работе Андроида, отключать ее мягко говоря не стоит. Ибо будут ошибки, возможно перезагрузки, зависания и так далее.

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

Когда в Google Services Framework происходит ошибка

Внимание! Гугл настоятельно не рекомендует удалять данные приложения, грозит что могут быть глюки:

1. Некорректная работа программ.
2. Необходимость постоянно входить в аккаунт.

Подробная информация — ссылка на официальный сайт (почитайте для интереса).

При возможности сделайте заранее бэкап/резервную копию системы. Это будет как страховка, которая в трудную минуту спасет.

Однако, на свой страх и риск можете все таки попробовать:

1. Открыть настройки.
2. Перейти в раздел Приложения.
3. Далее выбрать Google Services Framework.
4. Нажать Очистить данные, Очистить кэш.

Чтобы можно было увидеть системные программы, нужно нажать кнопку Меню в списке установленных программ > включить отображение системных приложений. В некоторых оболочках Андроида, например Samsung Experience, кнопки сброса кэша/данных расположены в подразделе Память.

При ошибках также дополнительно можно очистить данные/кэш приложений Google Play Маркет и Сервисы Google Play.

Вообще при ошибках, странных лагах советую также посетить форум 4PDA. Не реклама, просто самый крупный форум СНГ по Андроидам, поэтому и советую.

Источник

Модификация стоковых прошивок для Android. Часть 5. Революция c Xposed Framework

В 2012 году пользователь с ником rovo89 на комьюнити XDA опубликовал исходные коды и готовый к использованию фреймворк, упрощающий кастомизацию прошивок, с подробной инструкцией и примерами, предложив альтернативу традицоинному, на тот момент, способу (деодексирование→ дизассемблирование → декомпиляция → рекомпиляция → тестирование → загрузка патчей в телефон): Часть 1, Часть 2, Часть 3, Часть 4

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

Rovo не забросил свое детище, а продолжил развитие. Когда в 2013-ом году вышла версия KitKat, все то же сообщество именитых девелоперов ответило: «Неа, это слишком опасно… хотя. «

Тем временем Google принял решение выпускать новую версию операционной системы ежегодно. Разумеется, стало накладно кастомизировать прошивки: не успеваешь сделать одну, как появляется новая версия ОС. Так в 2014-ом выходит версия Lollipop и разработчики наконец обращают внимание на фреймфорк с мыслями: «Может все же стоит посмотреть что это такое? Выглядит многообещающим«.

В 2015-ом году вышла очередная версия (Marshmallow) и большая часть сообщества, в итоге, признала разработку весьма стоящей, на порядок сокращающей время разработки кастомизаций стоковых прошивок в виде установки отдельных модулей, расширяющих функционал. «Ничего себе, это же совсем безопасно и есть библиотека готовых полезных модулей!» — воскликнули они.

Сейчас конец февраля 2017-го. Xposed под Nougat все еще не доступен, а толпы страждущих разработчиков и пользователей то и дело открывают темы под тип «Xposed не работает! Он мне нужен! Rovo, пожалуйста!«

Сегодня я расскажу об Xposed Framework.

Отказ от ответственности

Любые названия продуктов и торговые марки, упоминаемые в тексте, являются собственностью их зарегистрированных владельцев. Тексты статьи опубликован в образовательных целях. Авторы (@Falseclock и xronofag) не несут ответственность за возможные убытки, порчу оборудования, недополученную прибыль вследствие попыток воспроизведения или использования информации в данной статье. Продолжая читать, читатель тем самым подтверждает, что любое использование исходного кода может повлечь для него риски.

Отступление

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

Я прождал около двух лет в надежде, что кто-то все же опишет на Хабре что такое Xposed Framework и как он может упросить процесс кастомизации приложений, но подозреваю, что мало кто знаком с этим чудным творением. Для своих нужд я написал несколько десятков модулей, некоторые даже публиковал в общем репозитарии, который на данный момент содержит более 1000 готовых к эксплуатации разработок. Каждый модуль — это может быть не одна единственная кастомизация, а целый набор функций с интерфейсом настроек или дополнительного функционала. Яркий пример тому GravityBox или Sense ToolBox.

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

Установка

Если раньше для установки сторонней прошивки требовалось производить разблокировку загрузчика телефона, то для использования Xposed пользователю необходимо всего лишь иметь root права на телефоне. Даже сейчас получение этих прав на большинстве девайсов не представляет больших сложностей: вы скачиваете приложение, а оно само делает все нужные манипуляции и через несколько минут вы становитесь обладателем телефона с уровнем прав «БОГ».

Принцип работы «на пальцах»

В системе Android есть процесс под название «Zygote». Это и есть основная исполнительная система. Любой процесс запускается как его копия. Zygote запускается через /init.rc как только загружается основное ядро системы. Запуск приложений осуществляется через скрипт /system/bin/app_process, который подгружает необходимые классы и запускает инициализацию приложения через задекларированные методы.

Именно в этом месте на сцену выходит Xposed. При установке фреймворка модифицированный app_process копируется в /system/bin. Суть модификации в том, что в переменную среду добавляется дополнительная jar библиотека, которая может исполнять специальные методы при определенных условиях и случаях. Например, мы можем вмешаться сразу, как только создается виртуальная машина Dalvik или даже перед тем как будет вызван основной метод Zygote. Являясь частью процесса Zygote, мы можем вмешиваться в работу любых методов, даже синтетических и производить любые действия в их контексте.

Практическая ценность Xposed

Предположим, необходимо изменить какой-то метод, и, например, вместо булева значения TRUE вернуть FALSE. Вместо трудоемкого и затратного традиционного метода (разбираем-собираем-тестируем приложение) вы можете «перехватить» этот метод класса и «вживить» свой Java код, который произведет необходимую операцию (изменит, в данном примере, значение) и вернет нужный нам результат. При этом, с Xposed можно: модифицировать или просто посмотреть какие данные передаются в метод, либо после исполнения метода узнать результат обработки данных и в зависимости от требований изменить их или воспользоваться ими.

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

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

А теперь главное — зачастую не приходится даже изменять работу модуля (или производить минимальные доработки) с выходом новой версии прошивки/приложения! Это логично, ведь названия методов, классов и переменных, как правило, остаются прежними.

Не правда ли, удобно?

Создание модуля

Сам модуль — это обычный apk файл, созданный в среде разработки. В нем не обязательно должно присутствовать какое-то Activity либо графические ресурсы. По сути там может быть только один файл с инструкцией, разумеется помимо обязательных файлов, и модуль может работать. Для настройки нам надо сделать три вещи:

Manifest.xml

При установке любого приложения Xposed проверяет наличие определенных заголовков в Manifest.xml. Если есть три нужные строки, то фреймворк сохраняет информацию о приложении в своих настройках и далее вы можете активировать установленный модуль (здесь и далее будут использоваться примеры кода разных модулей, в том числе и для из известных приложений).

С первой строкой все понятно.

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

Третья строка определяет как будет идентифицироваться ваше приложение в списке доступных или установленных модулей на вашем телефоне.

/assets/xposed_init

В корне вашего приложения необходимо создать папку assets и положить в него файл с названием xposed_init. Внутри этого файла вы просто пишите в каком Java классе описана работа вашего модуля. Я привык называть класс как XMain. В моем случае в файле присутствует строка

Java class

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

Метод initZygote исполняется тогда, когда ваш модуль загружается в память.
Весьма удобен, если в вашем приложении имеется Activity с настройками вашего модуля. Как правило, данные вашего приложения сохраняются в файл
/data/data/YOUR_PACKAGE_NAME/shared_prefs/YOUR_PACKAGE_NAME_preferences.xml . Во время загрузки вы можете единожды получить дескриптор и во время работы просто считывать с него ваши настройки. Также можно предопределить любые переменные, сделать проверки. По сути это аналог метода-конструктора.

Метод handleLoadPackage исполняется в тот момент, когда Dalvik загружает исходный код любого! приложения при запуске. Это очень важный момент. Если у вас в телефоне 10 различных модулей, то через этот метод исходники запускаемого приложения «прогонятся» во всех 10-ти случаях. Для фильтрации используется обычная проверка по названию пакета. Разумеется, если вы хотите изменить работу нескольких приложений, то ставите столько проверок сколько вам нужно.

Метод handleInitPackageResources нужен вам тогда, когда вы хотите подменить ресурсы приложения во время их загрузки в память. Здесь тоже самое как и с handleLoadPackage — вы фильтруете по названию приложения.

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

Примеры кода

Основной код, если вы конечно не решили всего лишь изменить цвета или шрифты какого-то приложения, происходят в handleLoadPackage. Для этого мы предварительно изучаем исходный код интересующего приложения, придумываем как модифицировать код и описываем нашу логику.
Основная логика работает через findAndHookMethod метод, реже через findAndHookConstructor и findClass. Все основные методы можно подглядеть в классе XposedHelpers.

Выглядит это примерно так:

В первую очередь нам надо обернуть наши «хуки» в try/catch, так как если в вашем коде будет ошибка, без обертки основное приложение может завершить работу c ошибкой, а полный трейс может попасть разработчику, который станет в курсе, что на его приложение наложили модуль. При обертке весь трейс можно вывести в лог Xposed и понять где у нас произошла ошибка и почему.

В findAndHookMethod первый параметр — это название класса, вторая — ссылка на загрузчик класса, третья — название нужного нам метода, далее идет перечисление в виде строк какие переменные передаются в метод и в конце наш callback метод.

Вот пример как можно заполучить контекст класса и воспользоваться им

В данном void методе вызывалось уведомление. Я его просто заменил и забыл что мне когда-то это мешало.

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

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

Доступ к переменным и методам класса осуществляется через класс XposedHelpers. Например:

Если объект является доступным импортируемым классом, то можно полученный объект сразу привести к нужному типу

и облегчить дальнейший код. Если же объект является каким-то типом внутреннего класса, который нам не доступен для импорта, в дальнейшем использование его методов и свойств также доступно через XposedHelpers.

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

В большинстве случаев достаточно отловить нужный метод и модифицировать либо изменить его логику можно сразу, как только приложение запускается. Но существует известная проблема с лимитом количества методов в одном DEX файле, поэтому многие громоздкие приложения имеют по 3-5 дополнительных DEX файла. Здесь скрывается подводный камень. Обойти его довольно таки просто:

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

Заключение

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

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

Источник