как узнать активити приложения андроид

Как узнать Activity Андроид приложения

Как узнать Activity Андроид приложения. Вам необходимо узнать Activity приложения Android? Тогда есть 3 способа как это сделать!

Подробней читайте в этой статье.

Итак перед вами стоит задача узнать Activity Android приложения, возможно вы разработчик, а возможно любитель автоматизировать какие либо действия или хотите запустить скрытые функции приложения, все это не так важно, цель достичь результата, поэтому приступим.

Способ 1: Узнать Activity Android приложения

Для этого вам понадобиться установленная Java JDK и утилита для декомпиляции приложения apktool.

Разобрав приложение открыть файл AndroidManifest.xml и там найти Activity приложения.

Способ 2: Узнать Activity Android приложения

Установить Android SDK и использовать утилиту AAPT (Android Asset Packaging Tool). Открыть командную строку и ввести следующую команду:

Способ 3: Узнать Activity Android приложения

Установите с магазина Goolge Play приложение Activity Launcher и перейдите в него.

Переключится на вкладку «все действия» и найти Activity application необходимого вам приложение:

Источник

Как узнать что активити запущено?

Оценить 5 комментариев

Сервис вообще для этой задачи надо использовать не так. Надо регистрировать BroadcastReceiver(лучше Wakeful) на аларм и бут_комплит, запускать сервис на время одной операции и завершать его, не забывая отпустить wakelock. Иначе он будет в активном ожидании, это очень плохо. Он будет не давать засыпать девайсу и высаживать батарею.

private static void setUpAlarm(final Context context, final Intent intent, final int timeInterval)
<
final AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
final PendingIntent pi = PendingIntent.getBroadcast(context, timeInterval, intent, 0);
am.cancel(pi);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP)
<
final AlarmManager.AlarmClockInfo alarmClockInfo = new AlarmManager.AlarmClockInfo(System.currentTimeMillis() + timeInterval, pi);
am.setAlarmClock(alarmClockInfo, pi);
>
else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT)
am.setExact(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + timeInterval, pi);
else
am.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + timeInterval, pi);
>

3(!) ТРИ различные способа установки алармманагера в зависимости от версии АПИ, в страшном кошмаре такое не приснится! кофейная гуща нервно курит в сторонке и отдыхает 🙂

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

Собственно и так не понятно кто/где и в какой момент инстанцирует экземпляр сервиса и активити

Рекомендую так же проанализировать ваш вариант с Preferences, если в нем не будет таких «багов», то это уже хорошо, несмотря на топорность. 🙂
Хотя не такое уж и топорное, сам UNIX многое хранит в файлах, и что.
Зато такой анализ полезнее, чем просто найти готовое решение в Android и надеяться, что вы все правильно сделали и что оно подойдет (хорошо, если это вообще так).

Источник

Как узнать Activity Android приложения?

Вам необходимо узнать Activity приложения Android? Тогда есть 3 способа как это сделать!

Подробней читайте в этой статье.

Итак перед вами стоит задача узнать Activity Android приложения, возможно вы разработчик, а возможно любитель автоматизировать какие либо действия или хотите запустить скрытые функции приложения, все это не так важно, цель достичь результата, поэтому приступим.

Способ 1: Узнать Activity Android приложения

Для этого вам понадобиться установленная Java JDK и утилита для декомпиляции приложения apktool.

Разобрав приложение открыть файл AndroidManifest.xml и там найти Activity приложения.

Способ 2: Узнать Activity Android приложения

Установить Android SDK и использовать утилиту AAPT (Android Asset Packaging Tool). Открыть командную строку и ввести следующую команду:

Способ 3: Узнать Activity Android приложения

Установите с магазина Goolge Play приложение Activity Launcher и перейдите в него.

Переключится на вкладку «все действия» и найти Activity application необходимого вам приложение:

У вас еще остались вопросы? Пишите их в комментариях, рассказывайте, что у вас получилось или наоборот!

Вот и все! Больше полезных статей и инструкций читайте в разделе Статьи и Хаки Android. Оставайтесь вместе с сайтом Android +1, дальше будет еще интересней!

Источник

Системный подход к тестированию Android-приложений, или О чем молчали разработчики

У каждого тестировщика рано или поздно наступает неловкий момент. Обнаружился вредный баг и его необходимо локализовать. По закону подлости баг воспроизводится нестабильно, при непонятных шагах и только на некоторых устройствах. Есть логи, но они не информативны. Разработчик занимается новой функциональностью, он не может отвлечься от текущих задач, пока не будут найдены четкие шаги воспроизведения. Менеджер ждет исправления (надо быстрее, заказчик переживает).

Как внести ясность в такой ситуации? Некуда деваться, пора разбираться, что же там происходит «под капотом» приложения.

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

Понимая, из каких компонентов состоит приложение, вы сможете:

Предлагаю разобрать некоторые компоненты Андроид-системы и со стороны тестирования рассмотреть кейсы, которые надо проверять для них.

Давайте сразу оговорим, что определения в статье давались тестировщиком. Они не претендуют на истину в последней инстанции и могут содержать неточности. Комментарии и аргументированные замечания приветствуются.

В Андроиде все основано на работе процессов. Операционная система может завершить процесс, если он завис или появился новый с более высоким приоритетом. Когда пользователь видит результаты деятельности процесса, система воспринимает этот процесс как самый приоритетный. И при необходимости она будет закрывать его в последнюю очередь.

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

Активити и фрагменты (activities and fragments)

С точки зрения тестировщика, активити можно воспринимать как экран, на котором отображаются элементы. Приложение состоит, как минимум, из одной активити. По сути, активити — это контейнер для UI-компонентов.

Если активити – это контейнер, то фрагменты – это UI-компоненты активити. Фрагмент тоже, в свою очередь, является контейнером для UI-компонентов.

Есть классная аналогия с браузером (спасибо разработчикам!) для более наглядного представления о том, как между собой связаны активити и фрагменты. Представим, что у нас открыто несколько окон одного браузера. Это несколько активити внутри одного приложения.

Внутри окна может быть открыто несколько вкладок. Это фрагменты внутри активити.

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

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

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

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

Жизненный цикл активити

Для тех, кто не знал или знал, но забыл.

Жизненный цикл активити представлен следующими состояниями:

Теперь приведу примеры. Они покрывают основные кейсы, с которыми мы чаще всего сталкиваемся при тестировании.

Первый запуск приложения

При первом запуске приложения создается и загружается главная активити в приложении.
При переходе в состояние «Resumed» активити доступна для взаимодействия с пользователем. Все замечательно, проблем нет.

Переход с первого экрана на второй

Шаг 1: При переходе с первого экрана на второй активити первого экрана сначала встает на паузу. В этот момент могут выполняться такие действия, как сохранение введенных данных и остановка ресурсоемких операций (например, проигрывание анимаций). Это происходит довольно быстро и неощутимо для пользователя.

Шаг 2, 3, 4: Запускается активити второго экрана.

Шаг 5: Останавливается активити первого экрана. Также в случае, если Андроид в этот момент пытается освободить память, активити первого экрана дополнительно может перейти в состояние «Destroyed» (то есть уничтожиться).

Чтобы лучше понять, что из себя представляет состояние «Paused» давайте представим такую ситуацию: экран, поверх которого появился алерт. Мы не можем с ним взаимодействовать, но в то же время мы его видим.

Возврат со второго экрана на первый

При возврате со второго экрана на первый происходит почти то же самое, только первая активити не создается заново. Она подгружается из памяти (если, конечно, не была уничтожена системой). Вторая активити уничтожается после того, как была остановлена, так как она убирается из стека переходов.

Сворачивание и выход из приложения

При сворачивании приложения (например, по кнопке Home) активити останавливается.
Важно, чтобы при разворачивании приложения активити корректно восстановилась и данные сохранились.

На всех экранах стараемся проверять сворачивание-разворачивание приложения. Этот кейс особенно актуален на формах ввода. Согласитесь, будет обидно, если текст письма, который вы так старательно набирали, сотрется при банальном сворачивании приложения. Или форма, состоящая из множества полей, снова станет пустой.

При выходе из приложения (по аппаратной кнопке назад) помимо шага 1 и шага 2, выполняется шаг 3. Активити уничтожается и при следующем запуске приложения создается заново.

Поворот экрана

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

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

Многооконный режим

Начиная с Андроида 7 (с Андроида 6 как экспериментальная фича) стал доступен многооконный режим. Пользователи получили возможность видеть сразу несколько приложений на экране одновременно. При этом только то приложение, с которым пользователь сейчас взаимодействует, находится в состоянии «Resumed». Остальные устанавливаются в состояние «Paused».

Don’t keep activities (Не сохранять действия)

Надо ли проверять полный жизненный цикл активити, если приложение не поддерживает поворот экрана? Конечно, надо.

Если оперативная память давно не чистилась, ее не очень много, и в параллели с вашим приложением было запущено какое-нибудь ресурсоемкое приложение (например, PokemonGo), то шанс, что Андроид решит «прибить» процесс с вашей активити при переключении на другое приложение, возрастает.

Как проверить корректность работы приложения вручную, если оно не поддерживает поворот экрана? Довольно просто: установить галку «don’t keep activities» в настройках разработчика и перезапустить приложение.

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

Это не значит, что галка должна всегда быть включенной при тестировании, но периодически смотреть приложение с опцией «don’t keep activities» полезно, чтобы пользователи со слабыми устройствами не сильно страдали и не ругали нас.

Broadcast receiver (широковещательный приемник)

Для обработки внешних событий используется компонент Broadcast receiver. Приложение может подписываться на события системы и других приложений. Андроид доставляет событие приложению-подписчику, даже если оно не запущено, и таким образом, может «мотивировать» его запуск.

При тестировании нам важно понимать, какие ожидаются события и как они обрабатываются.

Например, в коде заранее было прописано, что приложение ждет сообщение от конкретного номера и имеет доступ к смс. Когда пользователю придет секретный код, то Broadcast receiver получит уведомление и в поле подтверждения операции будет введен смс-код.

Сервисы (Services)

Еще одна очень важная вещь в Андроиде — это сервисы. Они нужны для выполнения фоновых задач. При этом приложение не обязательно должно быть открыто пользователем в этот момент.

У сервисов есть несколько режимов работы. Пользователь может видеть, что сервис запущен, а может и совершенно не замечать его.

Если вы услышали волшебное слово «сервис» от разработчика, не поленитесь, выясните, какую логику работы заложили в него:

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

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

Еще один тип сервисов это sticky-сервисы. Если работа такого сервиса внезапно завершится, то спустя какое-то время sticky-сервис «возродится». Примечательно, что с каждым разом период до «возрождения» увеличивается, чтобы он меньше мешал работе системы. В некоторых приложениях примером sticky-сервиса может быть скачивание файлов на устройство. Возможно, вы замечали, если в «шторке» сбросить закачку, то спустя какое-то время она может восстановиться и продолжить скачивать файлы.

Самые важные сервисы — те, работу которых пользователь «ощущает» на себе и она для него важна. Они называются foreground-сервисы, и у них обязательно есть нотификация в «шторке», которую пользователь не может закрыть. Система их будет уничтожать в последнюю очередь, так как приоритет у таких сервисов самый высокий.

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

Раз речь зашла о музыкальных плеерах, то стоит отметить такое понятие, как аудиофокус.

Аудиофокус

Представим, что при запуске нескольких аудиоплееров, они все будут играть одновременно. Вряд ли это кому-то понравится. Тут на помощь приходит аудиофокус, который запрашивается приложением у системы. В случае обычного запроса аудиофокуса система как бы оповещает все запущенные приложения: «Сейчас другое приложение будет говорить, помолчите, пожалуйста». Забавно, но это происходит именно в формате просьбы.

Если ваше приложение не очень вежливое, то оно спокойно может проигнорировать запрос. Наша задача – проверять эти ситуации.

Компромиссный режим запроса аудиофокуса называется «временным перехватом аудиофокуса». Это значит, что вашему приложению вернется аудиофокус, когда прервавшее его подаст системе сигнал, что аудиофокус освобожден.

Еще один вид запроса аудиофокуса — это «duck». Он просит остальные приложения не молчать, а уменьшить громкость наполовину пока воспроизводится звук запросившего фокус приложения. Например, такой запрос используется при проигрывании звука нотификации о новом сообщении в мессенджере.

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

На этом, пожалуй, пока можно закончить. Конечно, есть еще много деталей и нет необходимости учитывать абсолютно все при тестировании. По моему опыту, тестировщику необходимо понимать из чего состоит приложение и как оно работает. Это дает возможность анализировать непростые баги, которые возникают на пересечении бизнес-логики приложения и особенностей работы операционной системы. Особенно если дело касается Андроида.

Источник

Получение списка приложений в Android

Android SDK предоставляет много средств для работы с системой. В том числе он позволяет получать список приложений, которые установлены на устройстве. Это может быть полезно, когда нужно получить сведения о сторонних приложениях (размер APK, путь до приложения, имя пакета и т.д.). Например, в наших приложениях получение списка, содержащего сторонние приложения, играет большую роль: в GreenBro с помощью этого списка выводятся сведения о приложениях, а также выполняются различные действия.

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

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

Класс PackageManager

PackageManager предоставляет API, который фактически управляет установкой, удалением и обновлением приложений. Когда мы устанавливаем файл APK, PackageManager анализирует этот APK и выводит результат.

Получить экземпляр класса PackageManager можно с помощью метода getPackageManager(). PackageManager предоставляет методы для запросов к установленным пакетам и соответствующим разрешениям.

Где хранятся файлы APK на Android?

В зависимости от типа данных, на Androiid файлы могут храниться в следующих местах:

Как PackageManager хранит информацию о приложении?

Менеджер пакетов хранит информацию о приложении в трёх файлах, расположенных в /data/system.

packages.xml

Этот XML-файл содержит список разрешений и пакеты\приложения. Он хранит две вещи: разрешения и пакет. Например:

Разрешения хранятся в теге

. Каждое разрешение имеет три атрибута: name, package и protection. Атрибут name это имя разрешения, которое мы используем в AndroidManifest.xml. Атрибут package указывает на пакет, которому принадлежит разрешение, в большинстве случаев это «android». Атрибут protection указывает на уровень безопасности.

содержит 10 атрибутов и несколько подтегов.

Подтеги же здесь следующие:

содержат разрешения, которые разработчик установил в AndroidManifest.xml

packages.list

Это простой текстовый файл, содержащий имя пакета, идентификатор пользователя, флаги и каталог data.

package-stopped.xml

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

Получаем список приложений

Рассмотрим получение списка установленных приложений на примере GreenBro.

При запуске приложения запускается AsyncTask, внутри которого получаем экземпляр PackageManager и затем копируем в список List все данные об установленных приложениях.

Метод getInstalledApplications() принимает в качестве параметра флаг GET_META_DATA, который определяет, что нам нужные метаданные каждого пакета.

Результатом является список объектов ApplicationInfo для каждого установленного приложения. Класс ApplicationInfo предоставляет подробную информацию о пакете, собранную из тега в AndroidManifest.xml, нам оттуда нужны лишь самые важные данные.

Поэтому в цикле проверяем каждый объект из полученного списка и записывать данные в собственный класс AppInfo, чтобы затем использовать в основном потоке.

Здесь с помощью метода getPackageInfo() класса PackageManager мы получаем общую информацию о приложении по заданному имени пакета. После эта информация объединяется с информацией, полученной от getInstalledApplications() и сохраняется в объекте AppInfo со следующими полями:

Чтобы узнать название приложения, можно также воспользоваться PackageManager, как показано ниже.

Проверка же на то, является ли приложение системным, тоже достаточно проста и показана ниже.

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

Получение списка приложений в Android : 4 комментария

Подскажите пожалуйста, в конструкции:
final PackageManager pm = context.getPackageManager();
List apps = new ArrayList();
List packages = pm.getInstalledApplications(PackageManager.GET_META_DATA);
Чем является «context»?

Это локальная переменная, Вы можете передавать контекст из активити или фрагмента

» List packages = pm.getInstalledApplications( »

а есть ли функция наподобие getRunnedApplications(), которая выдает список запущенных последних приложений?

как отличить приложение от сервиса? Проверка на системное приложение не помогает

Источник