Advanced sample

  • Replace placeholder logic with your actual cross-profile implementation, ensuring it works and incorporating necessary context or parameters using the SDK.

  • Decide whether your cross-profile calls will be asynchronous or synchronous and ensure all parameter and return types are supported.

  • Refactor your code based on architectural suggestions for a production-ready structure.

  • Review for potential privacy and security issues, particularly concerning data storage and server communication from different profiles.

  • Consider additional recommendations such as designating a primary profile, refreshing UI based on profile availability, handling exceptions, and adding the android:crossProfile Manifest attribute if needed.

  • Add tests to verify your implementation.

  • Adjust permissions based on whether your app is full-consent or pre-granted, potentially switching to INTERACT_ACROSS_PROFILES with caution regarding Play store requirements.

This section assumes that you have already completed the hello world guide. It will take you through converting this into a full implementation. It often links out to the development reference sections of this document.

Switch out the logic from the hello world example for your real cross-profile logic

Feel free to keep it messy and not worry about best practices like testability yet. Make sure to check that it works!

This includes modifying the cross-profile class, the cross-profile calls, and the provider. If you need a Context in the provider method or the constructor of the provider class, you can add one as a parameter and the SDK will automatically provide it.

You will need to decide whether your calls will be asynchronous or synchronous . You should also ensure that all parameter and return types used by your cross-profile calls are supported.

Refactor your logic to have an architecture that you could submit

Read through each of the architectural suggestions first so you don't have to do multiple conflicting refactorings. Once you've planned out any changes, work back through them and check them off, re-building and testing after each change.

Double-check privacy and security

Double-check that you are not at risk of storing data in the wrong profile or sending data to a server (including server logging) from the wrong profile.

  • Consider designating a profile as primary to simplify your calls. Think about what happens if your logic is run on either profile.
  • Refresh your UI when the availability of the other profile changes.
  • Review the discussion of exceptions in case you need to take any action.
  • If you expect users might only use the app icon in one of the two profiles, add the android:crossProfile = "true" Manifest attribute. This prevents the app not directly used by the user from being delegated into lower app standby buckets.

Add tests

See testing documentation.

Consider permissions

  • If your app is full-consent, switch your permission from INTERACT_ACROSS_USERS to INTERACT_ACROSS_PROFILES and implement requesting the permission from the user. Apps declaring INTERACT_ACROSS_PROFILES can't be uploaded to the Play store until allow-listed, so this manifest change should be behind a flag until this is done.

  • If your app is pre-granted, you might also want to do this if you want to prompt users who previously turned it off (but be responsible - don't spam users).