Opened 7 years ago

Closed 7 years ago

#1325 closed defect/bug (fixed)

Android: action bar takes up screen real estate

Reported by: mvglasow (2) Owned by: cp15
Priority: minor Milestone:
Component: port/android Version: git master
Severity: normal Keywords: android
Cc:, (2)


The recent switch of the target API version from 7 to 19 has given Navit a contemporary look and feel, but it has the side effect of adding an action bar at the top of the screen, which reduces the space available for map display.

The only reason for having the action bar seems to be the menu button (or more correctly, the action bar overflow button).

I've googled around a bit, and the only way to get the legacy menu button in the navigation bar (at the bottom of the screen) is to target API 11, 12 or 13 and require a minimum API of 10 or lower. However, once we target API 14+ this no longer works – thus it's not really an option for us as it would bar us from using any of the more recent UI features.

Maybe we can find another way to bring up the Android menu and get rid of the action bar?

Attachments (2)

fullscreen.png (23.9 KB) - added by tryagain 7 years ago.
windowed.png (39.6 KB) - added by tryagain 7 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 7 years ago by mvglasow (2)

After a bit of research, here is my proposal:

  • Introduce a new OSD, which needs to be available on Android only (and included in the default XML config for Android). The OSD could probably share some code with the existing button OSD.
  • Touching the OSD would open up a popup menu, identical to the current Android menu. (If a physical menu button is present, its behavior remains unchanged – it brings up the menu.)
  • The OSD would display only if it is needed: If a physical Menu button is present, the OSD is hidden. Maybe we can even hide the OSD if the navigation bar has been customized to include a Menu button (which at least CyanogenMod? allows, not sure if that's a standard AOSP feature).
  • With the OSD in place, we could get rid of the action bar altogether and reclaim the space it is now taking up.

For further reference on popup menus in Android, see

comment:2 Changed 7 years ago by jandegr

Hi, If you want to get rid of the actionbar, all you need to do is restore the old theme in the androidmanifest, it is only sideways related to bumping target SDK. However if Navit targets a non-coders audience as well, the actionbar is a must have to improve the user friendlyness for new users, and should be further complemented to show the Android icons for search, settings and such. So another solution is to hide the actionbar when going fullscreen as an addition to the already disappearing notification area. Needs no new OSD or anything else and for convenience the coders audience can add the existing fullscreen button to their layout. Just would need to be tested on a pre-honeycomb device to verify it causes no problems. or a prebuilt apk from

Last edited 7 years ago by jandegr (previous) (diff)

Changed 7 years ago by tryagain

Changed 7 years ago by tryagain

comment:3 follow-up: Changed 7 years ago by tryagain


It seems to not work for me on Android 2.3.5, see attachments fullscreen.png, windowed.png. We still have some top bar with application name.

comment:4 in reply to: ↑ 3 Changed 7 years ago by jandegr

Replying to


It seems to not work for me on Android 2.3.5, see attachments fullscreen.png, windowed.png. We still have some top bar with application name.

Interesting, the first purpose of somebody testing it on a pre honeycomb device was to make sure that getActionBar() did not pose any problem since it was introduced in API 11, better safe than sorry. Apparently on pre-honeycomb devices the default theme holds a title bar with very little use contrary to the action bar. So I think we can remove a titlebar on those API's in onCreate() instead of doing it in fullscreen() as for the real actionbars.

Probably this addition will do for pre-Honeycomb :

I tested it on a real jellybean and lollipop device for the actionbar removal with fullscreen() and both passed.

Last edited 7 years ago by jandegr (previous) (diff)

comment:5 Changed 7 years ago by tryagain

Good work, jandegr!

It works for me now at 2.3.5 real device and on 2.2 emulator.

comment:7 Changed 7 years ago by mvglasow (2)

Good work – I just built Navit and gave it a quick spin on Lollipop. Looks good in fullscreen mode (at the expense of also hiding the main system bar), but in window mode the ActionBar? is still there.

I'd prefer having the main system bar but not the ActionBar?. I hardly ever use the Android menu so I don't need it, though other people may have other preferences. Maybe that can be made configurable?

As for UX, that is a potential holy war. My take on this is that Android is an OS for (literally) handheld devices whereas I would describe Navit as an app primarily for dash-mounted devices (even if the dash mount is temporary, as is the case with the phone in a dash mount), and the standard Android UX doesn't always take that into account. Though I am well aware that others might prefer the familiar Android look and feel.

On the other hand, an OSD button that displays the familiar "three dot" logo – and is preferably similar to Android's design for overlay buttons – should be fairly self-explanatory even to non-programmers, as long as they are somewhat familiar with the Android UI.

comment:8 Changed 7 years ago by tryagain

mvglasow, i almost agree with you but some ideas look a bit controversial to me in your last posting.

I agree that Android UX is not well suited for in-dash devices. But then why do you require system status bar? It's probably too tiny to see something useful in in-dash mode. I think all info useful at drive time should go into OSDs.

Some applications (browser, for example) seem to manage full screen status on the fly, displaying system bar when it's really becomes useful. We could switch it on (with or without action bar), for example, when the vehicle follow mode is off and user is, most probably, interacting.

Internal GUI can already be switched to deny popping it up on map tap and bound to a separate OSD button. Then we could bind full screen switch to single map tap, and it seems to be quite common for Android UX.

What i would also like, is to jump into internal GUI "clicked map point" submenu on long tap instead of currently displayed annoying "drive here" suggestion.

comment:9 Changed 7 years ago by mvglasow (2)

Well, again my personal take on this – others may see it differently. The status bar does have a few pieces of information that I like to have in view: time, GPS status (I use SatStat? that shows me whether or not I have a fix in a status icon), battery status and network status. Even in the car, I can make enough sense of the information: the GPS icon changes to an animation when I don't have a fix, the battery will display percentage next to it while charging and time is still big enough to read it. Also, I should probably elaborate on "in-dash": this covers not only the dash of my car, but also the cell cradle on the handlebars of my bike, where the viewing distance is shorter. For me, the system status bar has always been the perfect tradeoff between visibility of information and screen real estate economy.

One option we have in Android Lollipop and up (which would require some extra work, though) is to have transparent system bars, which could display on top of the map view just like the OSD does. We might want to give them a semitransparent gray background, just as with the OSD items. Graphics would also need to be modified – we want to use the full screen for the map, but we don't want the OSD to clash with the system bars – hence the map would need to use a different screen rectangle (bigger) than the OSD.

Vehicle follow mode – the only time I disable it is when I drag the map, and that is only for a brief time. That is, I frequently interact with Navit when screen following is on.

Full screen vs. internal GUI menu on map tap – as far as I can tell, that is already fully customizable in navit.xml. Note that this goes only for the internal GUI menu – I am not aware of any way to programatically bring up the Android menu. This is where my proposed OSD button comes into play. It can either be a purpose-built OSD (similar to toggle_announcer) with all the logic baked in to show only when needed and bring up the Android menu, or it can be a regular button. In the latter case, we'd need to implement a command to bring up the Android menu and an attribute to use in an enable_expression.

With these things in place, we'd have maximum flexibility. We would need to agree on some default config (preferably one that is self-explanatory to new users), but anyone who has different preferences can still edit navit.xml to their personal taste. These people are more likely to be advanced users (or devs) who are not afraid of tinkering with an XML file.

comment:10 Changed 7 years ago by mvglasow (2)

My implementation is finally ready. I've introduced an android_menu OSD, which is only available on Android and is included in the default XML files for Android. It presents a round button with the familiar three-dot icon and will show only when needed, i.e. when no physical Menu button is present. When touched, it will show the Android menu.

The menu button shows in the top-right corner as this is where the menu will appear. This required moving the "recenter map view" button next to the zoom buttons.

Internally the menu button calls a new command,, which can in theory also be used by other OSD items to bring up the Android menu. A new attribute, navit.has_menu_button, is used internally to determine whether or not to draw the button.

For now I've disabled the ActionBar? completely, as until now its only purpose was to show the Menu button. Though I'm open to selectively showing the ActionBar? if we decide to give it a real purpose (such as putting some action icons directly in the ActionBar?) – but that'll be a different ticket.

Code diff at

Last edited 7 years ago by mvglasow (2) (previous) (diff)

comment:11 Changed 7 years ago by tryagain

Good work! Behavior described is just like I was thinking it should be.

But I think we could better keep with input related attrs bound to graphics module. It makes sense that they are global, but all handling code is in graphics, and I do not think we will change it. Other similar attributes do not come to the mind, so I do not insist on this suggestion. But I'd like to make sure we do not break existing practice when going your way.

I have a stronger position with osd though. I'd better kept android specific code away from osd module. Is there any problem to implement it as a generic osd button and switch on/off with enable_expression attr?

Also, there seems to be at least one dbg output with lvl_error and debugging output.

comment:12 Changed 7 years ago by mvglasow (2)

dbg output is fixed, will be pushed soon. As for the osd, I'm currently running tests to see if it will work with a simple button. The enable_expression is currently causing some issues that need investigation.

comment:13 Changed 7 years ago by mvglasow (2)

Digging deeper into the code, I found a major obstacle to moving the has_menu_button attribute to graphics: The logic currently resides in graphics_android_new(). At the time the function gets called, nav points to a valid navit instance but nav->gra is still NULL. We'd thus have to somehow introduce an extra callback which runs when the graphics instance has finished initialization and then sets the attribute. All of this is made no easier by the fact that we can have multiple graphics_priv instances when overlays are used. Thus, attaching platform-specific attributes to graphics is going to be quite a hassle.

comment:14 Changed 7 years ago by mvglasow (2)

Got it. I've eliminated the dedicated OSD and implemented a button with an appropriate command and enable_expression, which gets added only on Android builds. (On other platforms, the enable_expression would never evaluate, thus preventing the button from showing.) I've kept the attribute in navit for the reasons mentioned above.

Code diff at ​

comment:15 Changed 7 years ago by mvglasow (2)

It took a while to clean up the code, mostly due to a fruitful discussion with sleske about good practice for committing (further reading:

Finally I've rebased my commits for a cleaner and more legible history, and opened a merge request:

If there are no objections I'll merge it in the next couple of days.

comment:16 Changed 7 years ago by mvglasow (2)

  • Cc (2) added

comment:17 Changed 7 years ago by mvglasow (2)

  • Resolution set to fixed
  • Status changed from new to closed

Merged the pull request, therefore I'm closing this ticket.

Note: See TracTickets for help on using tickets.