Android 11 is scheduled to be released this year in September, but we will get the first Android 11 beta version on June 3, 2020. The new Android version contains some new features and important developer focused updates, as seen in the developer previews. Android 11 features include airdrop-style file sharing, motion sense gesture, screen recording and many more. The behavior changes in the latest Android version may affect your app regardless of the target SDK version. So let’s get familiar with the behavior changes that will help you make your app compatible with Android version 11.

Accessibility

In the new Android, your accessibility service cannot declare an association with the system’s accessibility button at runtime. You can declare your accessibility service’s association with the accessibility button using the flagRequestAccessibilityButton flag in your accessibility service metadata file, typically res/raw/accessibilityservice.xml. Earlier we used to add AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON to the flags property of an AccessibilityServiceInfo object. But now the framework won’t pass accessibility button callback events to your service.

Open Mobile API changes

In Android 11, Open Mobile API has additional functionality:

1. Parse rules for carrier privileges.
2. Customize embedded Secure Element (eSE) access or provision an eSE using one or more of the following:

3. Provide readers a clear indicator for applications to filter device capability.

Security

The new Android stores each user’s app usage stats in credential encrypted storage. Therefore, neither the system nor any apps can access that data unless isUserUnlocked() returns true, which occurs if the user unlocks their device for the first time after a system startup or the user switches to their account on the device. If your app already binds to an instance of UsageStatsManager, check that you call methods on this object after the user unlocks their device. Otherwise, the API will return null or empty values.

Android 11 uses the Scudo Hardened Allocator internally to service heap allocations. Scudo is capable of detecting and mitigating some types of memory safety violations. Refer to the Scudo troubleshooting Android documentation if you see any Scudo-related crashes (for example, Scudo ERROR:) in native crash reports. Also, Android’s default SSLSocket implementation is internally built on top of Conscrypt SSLEngine.

App Compatibility

Android 11 update includes lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 11, some of these changes might not immediately affect you. However, while you can currently use non-SDK interfaces that are part of the greylist (depending on your app’s target API level), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API. To learn more about the changes in this release of Android, refer to Updates to non-SDK interface restrictions in Android 11.

Debugging

Android 11 offers debugging support for apps to identify potential JobScheduler API invocations that have exceeded certain rate limits. Developers can use this facility to identify potential performance issues. For apps with the debuggable manifest attribute set to true, JobScheduler API invocations beyond the rate limits will return RESULT_FAILURE. Limits are set such that legitimate use cases should not be affected.

The default mode for fdsan is changing in Android 11. It detects mishandling of file descriptor ownership, such as double-close and use-after-close. Previously fdsan used to log a warning and continue but now it aborts upon detecting an error. If you’re seeing crashes due to fdsan in your application, refer to the fdsan documentation.

Privacy Changes

There are some crucial changes in the privacy control in Android 11 and developers should review the privacy features and test their apps for compatibility. The first change we will talk about is One-time permissions. Now users can grant temporary access to location, microphone, and camera through a one-time permission. This feature grants more control to the users who do not wish to share information while using any app that uses these features. The next change is in package visibility. Android 11 changes how apps query and interact with other installed apps on the same device. Add the element to your app’s manifest and this change will affect the apps that target Android 11. There is an update for the background location access which will affect the apps that need all time access to location. Request foreground (coarse or fine) and background location permissions incrementally in separate calls to the permission request method. Before each request, use a full screen view to explain the benefits that users receive for granting that permission.

Apart from this there are many UI changes like system_alert_window permission and manage_overlay permission. For more information you can visit the Android documentation and also check out the behaviour changes in apps targeting Android 11.

We are glad to announce the release of pCloudy 5.4 with exciting new features to make app testing simpler than ever. There is a possibility that you might be familiar with pCloudy, but for those who are new, pCloudy is a cloud-based mobile app testing platform. We have achieved many milestones in a short period of time because we resolve issues immediately and bring in new features on a regular basis. Case in point: This new version of pCloudy, where we have addressed the concerns of our users and added new features to optimize testing. Let’s have a look at all the features added in pCloudy 5.4.

CTRL + V

To test your app on a pCloudy device you need to login to device.pcloudy.com and then book a device by clicking on the devices tab. Just click on the available button next to the chosen device which will take you to the device interaction page. Earlier in the device window, you would have to use the virtual extended keyboard to enter text in the device. Although now you can just copy any text from your system and paste it in the device directly. So now instead of using an extended keyboard just use two buttons to enter the string in the device. This will save time and effort when working with multiple devices where you need to enter long text many times.

FollowMe new UI

To use the FollowMe feature you will have to instrument the app you want to perform the test on. Under devices section, click on the FollowMe tab then in the next screen choose the app, select the duration and devices on which you will perform the test. In the next screen, you will see the devices which you selected and two options (Softkeys and Screenshots) at the top right corner of the window. Now when you perform any action in the master device, that action gets replicated on the secondary device too. If you enter text, tap on a button, swipe, etc. in the master device then that will happen simultaneously in the secondary device.


For more information, refer to this link:-

https://www.pcloudy.com/mobile-application-testing-documentation/manual-app-testing/follow-me-app-testing.html

Appium on Pre Installed Apps

In pCloudy, you can run Appium tests on multiple devices in parallel. To perform a test using Appium, you need to feed in the capabilities. Some users want to test their apps more than once to perform different types of tests on the same app. To do that earlier the users had to install the app again and again. But now we have released an update through which you can perform different types of testing using Appium on the preinstalled apps. This will save you time and make the process easier.


So if you have already installed the app in the device and you want to perform a test on the same app then you don’t need to pass the Application Name capability.

For more information, refer to this link:-

https://www.pcloudy.com/mobile-application-testing-documentation/automation-testing/inspect-element-using-appium-desktop.html#running-appium-scripts

GitHub Integration

pCloudy is integrated with the most popular tools and frameworks to make testing convenient. A lot of users also requested to integrate Github repository and so we did it. Now you can directly upload your tasks and raise defects in the GitHub repository from pCloudy. Again this feature is added to make it convenient for our users to test and manage the tasks through pCloudy.



To make use of GitHub just login to device.pcloudy.com and click on the user name at the top right corner of the window. In the dropdown list click on settings and in the settings window click on GitHub tab and enter the URL and access key to register. Now in the device session screen, you can click on Collaborate and then select Log a bug in GitHub. A new window will open where you will be able to see the list of repositories, enter the issue type, enter the title, add the description and then click on the click on the Log A Bug In GitHub button. Then you can go to the GitHub to check all the issues raised whenever you want.

Summary

We are working on some more new features and very soon we will come up with the new version of pCloudy. This is a constant process and we always try to address the users issues and provide them updates on a regular basis. This is why we are achieving new heights and we will keep on working hard to provide the best service.

Related Articles:

Latest OS Versions and Devices