After creating your module in Android Studio, open the AndroidManifest. You'll notice some standard app information in the application element, but there's also a uses-feature element that declares support for Android Automotive OS. Also note that there are no activities declared in the manifest. If you implement a Settings or Sign-in activities , add them here. These activities are triggered by the system using explicit intents and are the only activities that should be declared within the manifest for your Android Automotive OS app.
Explicitly setting these features to not required ensures that your app doesn't conflict with available hardware features in Automotive OS devices. This manifest entry refers to an XML file that declares what automotive capabilities your app supports. This file should include the following content:. Android Automotive OS uses explicit intents to trigger activities in your media app. Activities like the one in the following example usually target a phone, or some other mobile device.
These activities should be declared in the module that builds the phone app, not in the module that builds your Android Automotive OS app. We recommend that you keep your media browser service in a separate module that you share between your phone app and your automotive module. If you're using this approach, you need to update your automotive module to include the shared module, as shown in the following snippet:.
In addition to your media browser service, you can also provide vehicle-optimized Settings and Sign-in activities for your Android Automotive OS app. You should only implement these activities if your Android Automotive OS app needs to allow users to sign in or specify app settings.
These activities aren't used by Android Auto. The following diagram shows how a user interacts with your Settings and Sign-in activities using Android Automotive OS:. Figure 1. Settings and sign-in activity workflows. You can add a vehicle-optimized settings activity so that users can configure settings for your app in their car. Your settings activity can also provide other workflows, like signing in or out of a user's account or switching user accounts.
Remember that this activity is only triggered by an app running on Android Automotive OS. Phone apps connected to Android Auto do not use it. You must declare your settings activity in your app's manifest file, as shown in the following code snippet:. When a user launches your app, Android Automotive OS detects the settings activity that you declared and displays an affordance, such as an icon.
The user can tap or select this affordance using their car's display to navigate to the activity. The rest of this section shows how you can adapt code from the Universal Android Music Player UAMP sample app to implement a settings activity for your app. See the Android Settings guide for more information. As you implement your settings activity, refer to these best practices for using some of the components in the Preference library:.
If your app requires a user to sign in before they can use your app, you can add a vehicle-optimized sign-in activity that handles signing in and out of your app.
You can also add sign-in and sign-out workflows to a settings activity , but you should use a dedicated sign-in activity if your app cannot be used until a user signs in. To require a user to sign in before they can use your app, your media browser service must do the following things:. Set the media session's PlaybackState extras using the setExtras method.
Include the following two keys:. The following code snippet shows how your app can require the user to sign in before using your app:. Google offers a variety of identity tools that you can use to help users sign in to your app in their cars. Some tools, such as Firebase Authentication, provide full-stack toolkits that can help you build customized authentication experiences.
Other tools leverage a user's existing credentials or other technologies to help you build seamless sign-in experiences for users. We recommend the following tools to help you build an easier sign-in experience for users that have previously signed in on another device:.
Android Automotive OS apps that have authentication must use AccountManager for the following reasons:. If you need to request permissions from the user, use the same flow as the authentication activity or the settings activity in the activity workflows diagram.
For all errors, you should set an appropriate error code and error message in the PlaybackState. This causes a Toast to appear in the UI. When an error occurs but playback can continue, you should issue a non-fatal error. For example, a user might be able to play music in an app before signing in, but they must sign in before they can skip a song.
By using a non-fatal error, the system can suggest that the user should log in without interrupting playback for the current media item. In this case, you should preserve the rest of the PlaybackState as-is aside from the error code and error message. Using this approach allows playback for the current media item to continue while the user decides whether to sign in or not. On subsequent updates to your PlaybackState , you should clear the error code and error message to avoid displaying multiple warnings for the same error.
If at any point you are unable to load a browse tree—for example, if you require authentication and the user is not signed in—you should send an empty browse tree. To signify this, onLoadChildren for the root media node should return a null result. When this happens the system displays a full-screen error with the error message set in the PlaybackState.
If an error is actionable, additionally set the following two extras in the PlaybackState :. Actionable errors appear as a Dialog and can resolved by users only when the car is stopped. If applicable, implement offline playback support. Cars with Android Automotive OS are expected to have their own data connectivity, that is to say either a data plan included in the cost of the vehicle or paid for by the user.
However, cars are also expected to have more variable connectivity than mobile devices. As such, we recommend thinking about the best offline support strategy for your content.
The disk space on cars may vary, so ensure that users can delete offline content, for example through an option in your settings activity. Android Automotive OS does not currently support any commerce functionality. This means that you can't have a paid app nor any in-app purchases in your app. Users can purchase IAPs outside your Android Automotive OS app, but must not be required to do any additional commerce-related steps once in the car to use any new paid content or features.
WebViews are supported in Android Automotive OS but are only allowed for your settings and sign-in activities. When using a WebView, you are allowed to enable Javascript. Take all precautions possible to ensure that your WebView does not act as an entry point into the greater internet. See the code snippet below for an example on how to lock the WebView to the URL used in the loadUrl call and prevent redirects.
It is highly recommended to implement safeguards such as this when the use-case makes sense for example, when displaying legal-related links. Because you distribute a separate APK for Android Automotive OS, you have the option to reuse the package name from your mobile app or create a new package name. The main difference is that with a different package name your app has two completely separate Play Store listings, whereas if you reuse your current package name then you'll have a single listing across both platforms.
This is predominantly a business decision. The process of porting existing media apps that support Android Auto to this platform is simple and requires minimal development resources. Come talk to us in our sandbox, tune in via livestream on YouTube, or post on the automotive-developers Google Group or Stack Overflow using android-automotive tags. Talk about a life saver Whether you're talking, playing, working or streaming, you can feel confident about keeping your battery strong and full of life.
Express yourself in more ways than ever Emoji: Share the feels with a fully redesigned emoji set, including over 60 new emoji. A bird? A plane? No, it's Android Oreo.
Powers, and beyond Accessibility button. Accessibility volume. Accessibility services can optimize the audio experience for users with disabilities. Adaptive icons. Ambient screen. Background execution limits. More control over how apps run in the background for better overall system performance.
Background location limits. Limits the frequency of location updates in the background for better overall system health. Deep color. Android Automotive is a base Android platform that runs pre-installed IVI system Android applications as well as optional second- and third-party Android Applications. Android Automotive offers openness, customization, and scale to automotive infotainment systems and head units.
Openness enables new efficiencies by providing basic automotive infotainment features in a free and open source codebase. Customization enables implementers to differentiate the product as they see fit. Android Automotive is Android. Android Automotive is not a fork or parallel development of Android. It is the same codebase and lives in the same repository as the Android shipped on phones, tablets, etc.
Android Automotive extends Android.
0コメント