[Bug]: CarPlay map view never sets GMSMapViewOptions.screen, so the navigation header and footer are sized for the phone

Ouverte
  • Quelque chose ne va pas ?
#640 4 commentaires 1 réaction 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 5 jours

@jokerttu y travaille déjà.

Depuis le 28/8/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

Is there an existing issue for this?
  • I have searched the existing issues
Description of the bug

On a physical CarPlay head unit, a map view rooted in the CPWindow by BaseCarSceneDelegate renders its navigation UI at phone size. The guidance header's lane-guidance dropdown overlaps the ETA footer, and the type is far too large for the display. The map tiles and labels render correctly — only the navigation overlay is mis-sized.

GMSMapViewOptions has a screen property, added by the Navigation SDK's own category:

The screen the view will be used on.

Defaults to the main screen. Should be set to the CarPlay screen if this map view is to be used with CarPlay.

— GMSMapViewOptions+Navigation.h, GoogleNavigation 10.13.0

NavViewController.loadView never sets it:

GMSMapViewOptions *options = [[GMSMapViewOptions alloc] init];

if (_mapId && ![_mapId isEqualToString:@""]) {
  options.mapID = [GMSMapID mapIDWithIdentifier:_mapId];
}

if (_initialCameraPosition) {
  options.camera = _initialCameraPosition;
}

_mapView = [[GMSMapView alloc] initWithOptions:options];   // options.screen unset

grep -rn -i "uiscreen\|options.screen" ios example/ios/SampleApp at main returns nothing — not in the library, not in the CarPlay sample app. So every map view the library creates, including the one BaseCarSceneDelegate roots in the CPWindow, believes it is on UIScreen.mainScreen.

That the SDK does adapt to CarPlay is documented in GMSUISettings+Navigation.h: the trip progress bar "will not be shown for CarPlay displays" and "will only be shown when the GMSMapView is at least 552pt tall". It branches on the display and on height, and options.screen appears to be the public input for that — which the bridge never provides.

This is only visible if the app enables the navigation header/footer on the car screen. BaseCarSceneDelegate.onSessionAttached disables both by default and the sample does not override them, which is likely why it has gone unnoticed. Turning them on is the natural thing to do for an app that wants Google's turn-by-turn chrome on the console rather than building its own from didChangeNavInfo (per the guidance in #508).

Applications cannot work around this themselves: screen is an init-time option, there is no setter on GMSMapView, and NavViewController constructs the map view internally. It needs a fix in the library.

Suggested fix

Let the screen be supplied before the view loads, and have BaseCarSceneDelegate pass the car window's screen:

// NavViewController.h
- (void)setScreen:(nullable UIScreen *)screen;

// NavViewController.mm
- (void)setScreen:(nullable UIScreen *)screen {
  if (_mapView != nil) {
    RCTLogWarn(@"Cannot change screen after view is loaded");
    return;
  }
  _screen = screen;
}

// ... in loadView, before initWithOptions:
if (_screen != nil) {
  options.screen = _screen;
}

// BaseCarSceneDelegate.mm, in
// templateApplicationScene:didConnectInterfaceController:toWindow:
// — must precede the rootViewController assignment, which loads the view
self.navViewController = [[NavViewController alloc] init];
[self.navViewController setMapViewType:NAVIGATION];
[self.navViewController setScreen:window.screen];
self.navViewController.stateDelegate = self;

The phone NavigationView is unaffected — it never calls the setter and keeps the main-screen default.

I am running exactly this as a yarn patch. It compiles clean for x86_64 and arm64. I have not yet been able to confirm on a head unit whether it resolves the sizing, since I am waiting on a build — I will report back here either way. Happy to open a PR if the shape looks right to you.

React Native version

0.86.2

React version

19.2.3

Package version

0.16.3

Native SDK versions
  • I haven't changed the version of the native SDKs

(GoogleNavigation 10.13.0 / GoogleMaps 10.13.0, pinned via a config plugin for react-native-maps coexistence.)

Steps to reproduce
  1. Set up a CarPlay scene with BaseCarSceneDelegate as documented in CARPLAY.md.
  2. Override onSessionAttached to enable the navigation header and footer: 
    - (void)onSessionAttached {
  [self.navViewController setHeaderEnabled:YES];
  [self.navViewController setFooterEnabled:YES];
}
  3. Start a guidance session on the phone and connect to a CarPlay head unit.
  4. The header and footer render at phone scale; on a short display the header's lane-guidance dropdown overlaps the ETA footer.

Note this needs real CarPlay hardware — the CarPlay simulator currently crashes on iOS runtimes above 26.3 (#607).

Langage dominant
TypeScript
Étoiles
226
Forks
39
Merge moyen
1 j 20 h
PR mergées (30 j)
7

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de googlemaps/react-native-navigation-sdk

Toutes les issues de googlemaps/react-native-navigation-sdk

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.