# Advanced sample

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](https://developers.google.com/android/work/connected-apps/advanced-topics#asynchronous_calls)
or [synchronous](https://developers.google.com/android/work/connected-apps/advanced-topics#synchronous_calls)
. You should also ensure that all parameter and return types used by your
cross-profile calls are
[supported](https://developers.google.com/android/work/connected-apps/advanced-topics#supported_types).

> [!IMPORTANT]
> **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+.

## Refactor your logic to have an architecture that you could submit

Read through each of the [architectural
suggestions](https://developers.google.com/android/work/advanced-topics#architectural_recommended_solutions)
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](https://developers.google.com/android/work/connected-apps/advanced-topics#primary_profiles) to simplify your calls. Think about what happens if your logic is run on either profile.
- Refresh your UI when the [availability](https://developers.google.com/android/work/connected-apps/advanced-topics#availability) of the other profile changes.
- Review the discussion of [exceptions](https://developers.google.com/android/work/connected-apps/advanced-topics#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.](https://developer.android.com/topic/performance/appstandby)

## Add tests

See [testing
documentation.](https://developers.google.com/android/work/connected-apps/advanced-topics#testing)

## Consider permissions

- If your app is **full-consent** , switch your permission from
  `INTERACT_ACROSS_USERS` to
  [`INTERACT_ACROSS_PROFILES`](https://developer.android.com/reference/android/Manifest.permission#INTERACT_ACROSS_PROFILES)
  and implement requesting the permission from the user. Apps declaring
  [`INTERACT_ACROSS_PROFILES`](https://developer.android.com/reference/android/Manifest.permission#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).