feat: get installed packages information #502

shashank2086 · 2023-03-04T07:46:54Z

Getting all Installed and System apps of your device with Name and Main Activity for easily selecting and starting automation of any Application.

linux-foundation-easycla · 2023-03-04T07:46:58Z

The committers listed above are authorized under a signed CLA.

✅ login: shashank2086 / name: Shashank (f0ca48b, a058f4a)

mykola-mokhnach · 2023-03-04T13:35:05Z

What is the purpose of this extension? Packages querying could be easily implemented on the driver level via ADB.

shashank2086 · 2023-03-04T13:42:06Z

Well with Adb it only gives me package name of the application, Like for my requirement, i wanted to get more information like the app name for easy selection and The Activity name which i need to for creating a session. And also if appium server is giving me directly the app list then i don't need to run the terminal command.

mykola-mokhnach · 2023-03-04T14:17:26Z

Adb it only gives me package name of the application

Probably you just need to use a different command then. Generally, adb shell pm can fetch all needed information about installed packages.

shashank2086 · 2023-03-05T04:03:29Z

I have tried alot but couldn't find the commands to get exact information i wanted that's why i wrote this enhancement, I think it's more useful and efficient if the appium server is able to get me these informations as well.

app/src/main/java/io/appium/uiautomator2/server/ServerInstrumentation.java

KazuCocoa · 2023-03-05T06:28:42Z

adb shell dumpsys activity activities and adb shell dumpsys package <packagename> as well? Perhaps they will give more information though.

I'm curious about what information could get only via this

mykola-mokhnach · 2023-03-05T06:28:55Z

app/src/main/java/io/appium/uiautomator2/server/AppiumServlet.java

@@ -161,6 +162,7 @@ private void registerPostHandler() {

    private void registerGetHandler() {
        register(getHandler, new Status("/status"));
+        register(getHandler,new Getpackages("/apps"));


this is not a standard w3c endpoint, so we should not expose it like this. Consider adding this data into a custom /appium/device/... endpoint instead. Also, do you know how it is going to be called from the driver?

For driver, we have to add in the driver Wrapper SDK right?

I have changed the endpoint to /appium/device/apps

does it make sense to have this endpoint without a session id?

For driver, we have to add in the driver Wrapper SDK right?

There should be a driver endpoint, which would expose this information. You could implement it in two ways, either using a mobile: ... extension or by adding a custom API endpoint and assume that clients would add a support for it.

No they can utilize the API with driver also right, see i need it before creating session but it's not necessary for everyone, they can also utilize it after creating a session like every other APIs

I'm ok to add a new endpoint, if not a complicated feature to keep maintaining, but I'd request to add test code to check the function (in this repo, or via uia2 driver). Endpoints which are not in regular WebDriver protocol and not used by UIA2 driver regularly could break because we don't care so much for as our project. (Actually, fork is the most flexible way to maintain your own way as Mykola addressed.)

Well i can maintain it, but i think it's a quite a useful feature for the End User to have and i think it can be easily maintained and should not affect the existing implementation

I have already commented appium/appium-uiautomator2-driver#585
It is just not going to work without a session id.

If you really need to have the endpoint in this rep I can propose to create two handlers for it - one with session id and one without (session/:sessionId/appium/device/apps and /appium/device/apps ). The latter could be then used in custom calls, but since the code would be shared, we can guarantee it works as expected.

Okay makes sense, i will do that

app/src/main/java/io/appium/uiautomator2/model/api/touch/PackageModel.java

app/src/main/java/io/appium/uiautomator2/handler/Getpackages.java

mykola-mokhnach · 2023-03-05T06:37:32Z

app/src/main/java/io/appium/uiautomator2/handler/Getpackages.java

+            List<ApplicationInfo> apps = ServerContext.getPackageManager().getInstalledApplications(PackageManager.GET_META_DATA);
+            for(ApplicationInfo appInfo: apps) {
+                PackageModel model = new PackageModel();
+                if(ServerContext.getPackageManager().getLaunchIntentForPackage(appInfo.packageName)!=null) {


the package manager instance should be retrieved once.

adb shell dumpsys activity activities and adb shell dumpsys package <packagename> as well? Perhaps they will give more information though.

I'm curious about what information could get only via this

Well first command will only give information of the activities information of the current opened application, and also the main issue is reading the dumpsys is another headache, maybe we can achieve but this seems the more efficient way of doing

Thank you. So, this pr aims to show a few information which could be part of adb shell dumpsys package <packagename> via UIA2 server process instead of adb command, correct? (to clarify the intention)
package name, an activity name which is specified as launcher category and the package name.

Yes exactly, So is packageName and activityName correct? or should i rename to any other name for better understanding?

mykola-mokhnach · 2023-03-05T06:39:38Z

Please assign a proper name to the pull requests according to https://www.conventionalcommits.org requirements

app/src/main/java/io/appium/uiautomator2/model/api/touch/PackageModel.java

KazuCocoa

forgot to submit a comment in addition to a question about adb shell dumpsys activity activities and adb shell dumpsys package <packagename>

app/src/main/java/io/appium/uiautomator2/handler/Getpackages.java

Formatting

app/src/main/java/io/appium/uiautomator2/handler/GetPackages.java

app/src/main/java/io/appium/uiautomator2/model/api/touch/appium/PackageModel.java

KazuCocoa · 2023-03-06T18:42:21Z

app/src/main/java/io/appium/uiautomator2/handler/GetPackages.java

+            // Filtering out unnecessary sub packages without Intent
+            if (manager.getLaunchIntentForPackage(appInfo.packageName) != null) {
+                appDetails.add(new PackageModel(appInfo.packageName,
+                        manager.getLaunchIntentForPackage(appInfo.packageName).getComponent().getClassName(),


What happen when getLaunchIntentForPackage(appInfo.packageName) is null, or getComponent is null. They are nullable.

They both are Nullable, if an application has an intent then for sure it will have a component, so application with no component will automatically get filter out from the 46 condition and also getComponent is also Nullable

ah, missed here called the method twice.
This endpoint tries to show installed packages and each information, then maybe if would be nice to keep the package name (since it exists) but no activities rather than filtering the package out entirely. What do you think?
So, the user can understand some packages exist in the device but they has no launchable activities by this endpoint.

The intend was to show all the main applications since the package without Intent is just a subpackage of it's parent package which can just create confusion to the user and actually it's pretty much useless, if later on anyone needs that then surely we can modify accordingly but i feel it's unnecessary right now to show?

Then, could you leave the intention as docstring in this class for future maintenance?
GetPackages made me think the app package is primary, then app activities etc as additional information. The current intention is to get app activities information than its package (since filter by package).

I have already given a comment on that condition, You want me to create docstring with more info?

Yea, could you leave what kind of activities will be available, and no activities packages won't be available?
I mean not a comment for the implementation, just this method's entire behavior as the module's description. Also, it wole be appreciate to add this method uses android.permission.QUERY_ALL_PACKAGES here, or a comment in the manifest to link each

Sorry, missing commit?

app/src/main/java/io/appium/uiautomator2/handler/GetPackages.java

app/src/main/java/io/appium/uiautomator2/model/api/touch/appium/PackageModel.java

shashank2086 · 2023-03-07T12:07:12Z

Can it be merged now?

app/src/main/java/io/appium/uiautomator2/handler/GetPackages.java

app/src/androidTestE2eTest/java/io/appium/uiautomator2/unittest/test/DeviceCommandsTest.java

app/src/main/java/io/appium/uiautomator2/handler/GetPackages.java

mykola-mokhnach · 2023-03-09T17:37:54Z

@KazuCocoa Do you have any additional comments?

## [5.8.0](v5.7.8...v5.8.0) (2023-03-09) ### Features * get installed packages information ([#502](#502)) ([94dcd37](94dcd37))

KazuCocoa · 2023-03-09T17:41:12Z

no, just waited for the ci result

github-actions · 2023-03-09T17:41:25Z

🎉 This PR is included in version 5.8.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

shashank2086 added 2 commits March 4, 2023 13:09

Getting all packages with Main Activities

f0ca48b

endpoint name change

a058f4a