Develop Reference

Unable to Inspect Object com.android.incallui.service.SecCallPopupService on Samsung J5

I have a problem that I think is related with Android permissions, however I need some of your expertise to confirm it.
I have testing the old Samgung J5(Not rooted) with Android 8.1.0, Appium 1.10.0 with UiAutomator2 and ADB 10.0.40 (In administration mode) on some Call Handling scenarios where I need to check if determined display elements (identity, call duration, hold activated, on transfer information, etc) are displayed to user. I have seen multiple solutions to do this task, inclusively using adb to do it, but lets focus only on this problem, using only the display elements (GUI).
Scenario, user receives call.
The com.android.incallui.service.SecCallPopupService comes into action:
User receives call
When I try to inspect the com.android.incallui.service.SecCallPopupService window the Appium cannot found it:
Appium Inpector
Neither on UiAutomatorViewer:
UitAutomatorViewer
On Comment link (xml dump) you can seen the display elements that Appium, and UiAutomatorViewer can "see". Same result was obtained by using the command adb shell uiautomator dump /data/local/tmp/uidump.xml
After that, I installed the Appium Studio and try out the Appium official "Inspector" and the result was:
Appium Studio Object Spy with full access to all display elements. Very intriguim... after some research I found the following package com.experitest.uiautomator.test (running in background) was immediatelly installed on the device when I clicked on Object Spy feature and I think that is responsible to retrieve all the interface elements.
On comment link (logcat) Some logcat logs after doind object spy on Appium Studio:
Analysing the logcat we can see that Appium studios was requesting
{"response":"true","params":[],"command":"richDump"} and the package uses
some kind of node:android.view.accessibility.AccessibilityNode. Maybe using something like the Acessibility Tree node to get the elements ? I don't know...
I have read some similar questions on Stackoverflow but some solutions involves to root the device or using de ADB (its not an option),
Tryng to su root the device and chmod 777 /data/local/tmp, but if it's really necessary, how then Appium Studio can read all display elements?
Do you know any other solution that allows me to get all interface elements without root the device? How can I call the "richDump"?
Thank You for you help.

Run an instrument test from within app and wait for result

I am developing a QA automation solution that can record/playback QA tests on Android. A key business requirement is to have no dependency on a connected PC while playing back the recorded test. To that end, I'm trying to run an Instrumentation test without a connected PC. (Specifically, an Appium UiAutomator2 test).
My current approach is trying to run the test programmatically from my app. If I were running the test normally from a connected PC, I would use the command adb shell am instrument -w. I tried accessing ADB Shell from my app and running am instrument -w, but this produces an error that I am missing the INTERACT_ACROSS_USERS_FULL permission.
To get around this issue, I am trying to run the test using startInstrumentation. This successfully starts the test. However, the test immediately crashes. Upon further investigation, I traced the crash to an NPE: the test is trying to retrieve InstrumentationRegistry.getInstrumentation.getUiAutomation(0), but this returns null.
How do I run the test programatically and give it access to the required UiAutomation instance?
This is how I start the test:
public void runTest() {
final String pm = getPackageName().replaceFirst(".test$", "");
final InstrumentationInfo info = getInstrumentationInfo(pm);
if (info != null) {
final ComponentName cn = new ComponentName(info.packageName,
info.name);
Bundle arguments = new Bundle();
arguments.putString("class", "io.testim.appiumwrapper.test.AppiumUiAutomator2Server");
//cn = {io.extension.test/android.support.test.runner.AndroidJUnitRunner}
startInstrumentation(cn, null, arguments);
}
}

see signature protection level - clarifying ...unless having the package white-listed by Google's release key, you won't be able to obtain the necessary permission. this is a security/integrity feature, with the purpose to limit what malware is able to do - and what you intend to do there, is typical malware behavior - no matter the actual intention of it; working against the system leads nowhere.
the only way I could imaging would be to run commands directly from a terminal emulator or the test application - against a custom build of AOSP, so that you could add android:protectionLevel="signature" to the Manifest.xml and then require android.permission.INTERACT_ACROSS_USERS_FULL. but with a stock ROM, there definitely is no chance to do so. it is not, that it would be "impossible", but building a custom ROM means quite some effort, in order to get there. at least for Nexus and Pixel devices, the required drivers are available here; for other devices, you'd have to find them at the device's vendor, if they're even available.
the trick is to sign off the ROM with the same key as the app - only then signature level permissions can be obtained - while for a stock ROM, you'd (theoretically) need Google's release key to sign off the package. one can enforce single user, as explained here, while this also is only available to system apps.

Programmatically accessing the KNOX counter

How can you access the KNOX counter programmatically from the android SDK?
I would like my app to check the value to try and ascertain if it is running on a samsung phone that has been rooted.

I just decompiled KNOX Status. It looks like all the app is doing is getting the system property ro.boot.warranty_bit. I'm not sure if this still works and I don't have a Samsung at the moment to test.
In terminal run:
adb shell getprop ro.boot.warranty_bit
If the result is 0, then the warranty should be valid. You can use this class to get the system property in an Android app.

USB-Webcam on Android 4.4+

I am into a new project which requires me to use a USBconnected "Webcam".
The whole fun should run on Android 4.4.
my little story was:
I try multiple apps which do this - all work on both my testing devices
adapting some NDK lib that directly uses /dev/video0. This didnt work due to read-permission that was not granted in a new File("dev/video0").canRead() check. Although my unix permissions are correct, this seems to not work due to some new check on Android 4.4. (the whole thing was suggested here: Connect Android phone to a USB Web camera )
next: discover the UsbAccessory API that supposedly easens a lot of the above.
´find no documentation or anything about how to correctly handle a webcam
I still try, but don't come further than finding no device via
usbManager.getAccessory();
I've also tried to discover devices by filtering for a USB_ATTACHED broadcast but nothing triggers.
So I am starting to ask myself how the hell do others find the devices & communicate with them to get the pictures?
Anyone has sources from which i could learn, or a tutorial or something?
Little update from my side:
- I've gotten access by using the Android USB Host API e.g. UsbDevice instead of UsbAccessory.
- I have the connection and everything setup fine, and can now send binary data to my webcam and supposedly receive.
I can now send controlCommands via connection.controlTransfer(...) or use a "UsbRequest" in order to receive data.
However, I couldn't find any documentation to "make the camera submit pictures" to me. My Endpoint is of type XFER_INT (=interrupts).
I am continuing to try sending out various commands (e.g. binary values) but haven't had any success so far.

Can I run Appium for mobile with no target app?

Since I'm working in a platform which works with many apps (rather than a single target app), I find the selection of a target app inefficient for my needs. I wondered if I could do something to avoid it.
I'd like to run freely, sending UI commands to iOS and Android real devices, including installing an app from another app (like Play Store, Apple Store, Test Flight, etc.)
Thanks for the help,
David.

The rule is: 1 Webdriver instance per application.
You can run Appium's server with no --app argument by making sure auto-launch is set to false, and not setting bundleId or app.
Then, in your client/test framework, you use several webdrivers, configured to use different desired capabilities, to tie it all together under a single test case/suite.
The solution:
You may have a test suite that sets desired_capabilities to launch the Safari app, then you install the app, then you quit the webdriver.
Then you change the desired_capabilities to point to the bundle_id of the new app, launch another webdriver instance, do your tests, quit the webdriver..
Then you change the desired_capabilities to point to (etc., etc.)
driver = webdriver.new(url, desired_capabilities)
// do some stuff
driver.quit()
desired_capabilities['app'] = 'company.app.com'
driver = webdriver.new(url, desired_capabilities)
// do some stuff
driver.quit()
desired_capabilities['app'] = '/path/to/application.app'
driver = webdriver.new(url, desired_capabilities)
// do some stuff
driver.quit()