Stay organized with collections
Save and categorize content based on your preferences.
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 other recommended solutions
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.
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).
[null,null,["Last updated 2024-10-31 UTC."],[[["\u003cp\u003eReplace the placeholder logic in the hello world example with your actual cross-profile logic, focusing on functionality before optimization.\u003c/p\u003e\n"],["\u003cp\u003eRestructure your code according to the recommended architectural patterns to ensure maintainability and scalability.\u003c/p\u003e\n"],["\u003cp\u003eVerify the security and privacy of your implementation, paying attention to data storage and server communication within the correct profiles.\u003c/p\u003e\n"],["\u003cp\u003eExplore advanced features like primary profile designation, UI updates based on profile availability, exception handling, and app standby bucket management.\u003c/p\u003e\n"],["\u003cp\u003eThoroughly test your cross-profile functionality and consider necessary permission updates for seamless user experience.\u003c/p\u003e\n"]]],[],null,["# Advanced sample\n\nThis section assumes that you have already completed the hello world guide. It\nwill take you through converting this into a full implementation. It often links\nout to the development reference sections of this document.\n\nSwitch out the logic from the hello world example for your real cross-profile logic\n-----------------------------------------------------------------------------------\n\nFeel free to keep it messy and not worry about best practices like testability\nyet. Make sure to check that it works!\n\nThis includes modifying the cross-profile class, the cross-profile calls, and\nthe provider. If you need a `Context` in the provider method or the constructor\nof the provider class, you can add one as a parameter and the SDK will\nautomatically provide it.\n\nYou will need to decide whether your calls will be\n[asynchronous](/android/work/connected-apps/advanced-topics#asynchronous_calls)\nor [synchronous](/android/work/connected-apps/advanced-topics#synchronous_calls)\n. You should also ensure that all parameter and return types used by your\ncross-profile calls are\n[supported](/android/work/connected-apps/advanced-topics#supported_types).\n| **Important:** Add version checks. For **cross-user apps**, the SDK calls will only work on Oreo+. For everybody else, the SDK calls will only work on Android 11+.\n\nRefactor your logic to have an architecture that you could submit\n-----------------------------------------------------------------\n\nRead through each of the [architectural\nsuggestions](/android/work/advanced-topics#architectural_recommended_solutions)\nfirst so you don't have to do multiple conflicting refactorings. Once you've\nplanned out any changes, work back through them and check them off, re-building\nand testing after each change.\n\nDouble-check privacy and security\n---------------------------------\n\nDouble-check that you are not at risk of storing data in the wrong profile or\nsending data to a server (including server logging) from the wrong profile.\n\nConsider other recommended solutions\n------------------------------------\n\n- Consider designating a profile as [primary](/android/work/connected-apps/advanced-topics#primary_profiles) to simplify your calls. Think about what happens if your logic is run on either profile.\n- Refresh your UI when the [availability](/android/work/connected-apps/advanced-topics#availability) of the other profile changes.\n- Review the discussion of [exceptions](/android/work/connected-apps/advanced-topics#exceptions) in case you need to take any action.\n- 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\n buckets.](https://developer.android.com/topic/performance/appstandby)\n\nAdd tests\n---------\n\nSee [testing\ndocumentation.](/android/work/connected-apps/advanced-topics#testing)\n\nConsider permissions\n--------------------\n\n- If your app is **full-consent** , switch your permission from\n `INTERACT_ACROSS_USERS` to\n [`INTERACT_ACROSS_PROFILES`](https://developer.android.com/reference/android/Manifest.permission#INTERACT_ACROSS_PROFILES)\n and implement requesting the permission from the user. Apps declaring\n [`INTERACT_ACROSS_PROFILES`](https://developer.android.com/reference/android/Manifest.permission#INTERACT_ACROSS_PROFILES)\n can't be uploaded to the Play store until allow-listed, so this manifest\n change should be behind a flag until this is done.\n\n- If your app is **pre-granted**, you might also want to do this if you want\n to prompt users who previously turned it off (but be responsible - don't\n spam users)."]]