enviroCar Light


The enviroCar project allows users to collect and share their driving data via a mobile application and an ODB-II adapter. However, the collection of driving data using the mobile application for enviroCar requires a number of manual user interactions. This is unpleasant and tedious over the long run and poses a major obstacle for using the app regularly.

To tackle these problems, the enviroCar light project aims to enhance the usability of the enviroCar application by simplifying and automating the workflow of collecting driving data in order to achieve more regular user contribution.

You can follow my progress on enviroCar-app github repo in the GSoC branch.

Final Blog Post Demo

A compiled version of the last stable state can be found here.

Instructions to install the app:

Before you can install the apk on your phone you will need to make sure that third-party apps are allowed to be installed on your device. This can be done as follows
  • Go to Menu -> Settings -> Security -> check "Unknown Sources" to allow the installation of apps other than the play store
If an old version of enviroCar has already been installed, then first uninstall it like follows.
  • Go to Menu -> Settings -> Apps
  • Click on the enviroCar app and then uninstall it.
To install the new apk you have to do the following:
  • Put the apk somewhere on your smartphone where you can find it.
  • Use, for instance, the Astro file manager to install the app
  • Install and start Astro and navigate to the place where you stored the apk.
  • Click on the apk and install it.


Week 13 (17-23 August)

  • Finalized most of the implementations.
  • Implemented a new graph representation to the track details activity. Currently, its only showing a speed graph over the time (could be easily extended to any attribute the device is recording).
  • Optimized the new list fragment and its map preview. Now, the preview correctly renders the complete extent of a track.
  • Optimized and fixed the notification handling and corrected the auto-discovery of other devices.
  • Fixed the issue of multiple initiated discoveries of other devices.
  • Fixed the issue in which the new map representation of a dashboard keeps the GPS active. Now, when the app gets closed, the GPS should be correctly deactivated.

  • none

Next Steps
  • Keep fixing further bugs
  • Documentation
  • Finalizing the project.

Week 12 (10-16 August)

  • Finalized the track recording fragment and its header fragment that shows some of the track details.
  • Finalized a live map representation that shows the recorded track so far and follows the position of the car.
  • Implemented a TrackDetailsProvider that computes track statistics based on different internal events (e.g. average speed, distance, average fuel consumption, duration etc.) at runtime.
  • Implemented the functionalities in the header fragment in the dashboard. Now, this view shows the average speed, distance, duration, and the state of the Bluetooth connection and GPS.
  • Fixed several bugs of the fragment transition.
  • Testing, testing, and more testing with different devices and Android versions.
  • Fixed the bug in which every second measurement of a track recording only contained null values.
  • Documentation.

  • Different behavior on different Android devices with different Android versions

Next Steps
  • Texting and bug fixing is the most important task for this week.
  • opt-out the speed map overlay representation of a track
  • Optimizing the live map and integrating some functionalities there (e.g. different zoom levels for different speeds, optional button for following the car)

Week 11 (3-9 August)

  • Further implemented on the general track recording fragment. This fragment consists of different sub fragments and views to show, starting with a map based fragment and possibilities for making the most important settings (selecting a car type and obd adapter). This enables the user to directly see the settings to made to get the app running (not finished yet!).
  • Implemented several view transition-based animation in the previous fragment (not finished yet!).
  • Implemented a first version of a speed based map overlay that shows a colored trajectory of the track. However, this overlay sufferes from extreme performance issues yet and needs to be further optimized. The current implementation colors the trajectory of the track quite naive, such that further work has to be made here .
  • Implemented a MapView that shows and follows the current position of the device (will be used for a live-map view)
  • Optimized the ID-retrieval for a car type, because the old was kind of buggy and under some circumstances gets blocked by other parts of the app.
  • Documentation.

  • Some problems caused by the poor API of the app and its documentation...
  • Had a problem with this Android bug related to nested fragments. A workaround has been implemented.

Next Steps
  • Finalizing the track recording fragment (startup fragment) and its different views.
  • Integrating a live-map representation as an alternative dashboard representation. The map view should show a speed-based trajectory overlay of the track and
  • Implementing functionalities in the header of the dashboard fragment, which show the statistics of the track.

Week 10 (27 July - 2 August)

  • Had to find the reason for the reinstallation bug.
  • Finalized the "functionality" (not the layout) of the car selection.
  • Completely reimplemented the way the used car type is stored and extended it to multiple cars. Now, a user is able to use multiple cars.
  • Reimplemented the "distribution" of a new car within the app and used the event bus system instead.
  • Finalized the basic list representation as alternative and more ordered representation to the car representation.
  • Continued implementing the startup fragment which now shows the very basic settings used for a track.
  • Extensive testing of the app and the new concepts.
  • Some minor bug fixes.

  • Found a bug in which every second measurement of a track is completely 0 with all values. So far I was not able to narrow down the source of the problem.

Next Steps
  • Finalizing the startup fragment.

Week 9 (20-26July)

  • Implemented some of the interactions in the new list representations (e.g. deleting, uploading, sharing).
  • Started implementing an additional and more compact list representation as an alternative to the card representation.
  • Started implementing a new car selection (note that there is nothing to show so far)
  • The dialog for selecting a new car is based on EditTexts with autocomplete functionalities. The autocomplete works based on the known cars received from the server. When a user selects a manufacturer, then the auto complete for the model only uses known models for the selected manufacturer.
  • Removed some bugs and blocking behavior in the car DAOs. The car receiving methods are now based on reactive programming. (In general, the overall API could greatly benefit from a more reactive programming style.)

  • The problems are too specific to explain.

Next Tasks
  • Continue with the list representation.
  • Continue with the car selection.

Week 8 (13-19 July)

Github commit can be found here.
  • Integrated MapBox SDK to replace the very outdated Mapsforge library.
  • Implemented a new Tracklist based on the RecyclerView and CardView.
  • The CardView representation of a track also provides a map-based preview of the track and the most important characteristics.
  • Implemented an activity that shows the details of a track including a proper map representation.
  • The transition between the track list and the details of a track works fluently with the aid animations.
  • The design and animations of the implementations is following the guidelines of the Material Design

  • Using CoordinatorLayout view anchors causes margins of views to be ignored (see here). Spent a lot of time to find a workaround.

Next Steps
  • Implementing an alternative list representation for the CardView representation. A user should be able to switch between both list views.
  • Divide the track list into two different lists consisting of local and remote tracks.
  • Trying to find a more intuitive interaction with the app. On startup, it is kind of unclear what to do in order to connect to a car.
Some impressions:

nav_drawer.png new_dashboard.png track_cardview1.png trackdetails_1.png trackdetails_2.png trackdetails_3.png

Week 7 (6-12 July)

  • Implemented a setting in the settings fragment for the TextToSpeech functionality. Now, it is possible to deactivate the TextToSpeech
  • Re-implemented and re-designed the navigation drawer, because the old one mixes functionalities with views (i.e., fragments and start track button) and the drawer was not following any design guidelines (e.g., icons do not align at screen margins).
  • Significantly simplified the code related to the navigation drawer and its extensibility by using the support design library and android resources.
  • Started to re-design the dashboard fragment including new cruise control visualization and a darker representation of the dashboard fragment, which should save battery.
  • The cruise control is implemented to deal with any scale and display resolution.
  • Documentation.

  • Canvas visualization using a Android version >5.0 leads to annoying problems when working on a scale below 1.0f.

Next Tasks
  • Implementing the functionality of the dashboard. So far, the new dashboard is only showing some kind of mockups.
  • Integrating MapBox Android SDK.
  • Re-implementing the "My Tracks"-list using a cardlayout, a RecyclerView, and some part of map representation.

Week 6 (29 June - 5 July)

  • Re-implemented the DashboardFragment, because it was tightly coupled to other parts of the application such that it loses its flexibility (e.g., DashboardFragment was required to be visibile to register for OBD-related updates on start and, if this was not the case, the DashboardFragment did not received the right events to show). Now the implementation consideres the new event bus, dependency injection, and view injection, which makes it as flexible as required.
  • Integrated ButterKnife for ViewInjection, because it is easy and significantly simplifies the code by removing unnecessary boilerplate code. ButterKnife does all the necessary view lookups that are required for some "visible stuff".
  • Finished the autoconnect to the OBDII adapter and integrated settings related to the autoconnection (i.e., setting for auto-start background service once the bluetooth has been activated, setting for automatically start a track once the device has been successfully discovered, and a setting for the discovery interval of the background service).
  • Finished the handling of notifications in the notification area and the notification drawer. Now, the notification always shows the right state of the application (i.e., unconnected state, discovering state, track started state, etc.) and provides direct interactions with the application to the user (e.g., start track, discover for OBD, stop track etc.)
  • Fixed a bug related to the SQL data base and the newer APIs.


  • There were some problems with the underlying SQLite database and the way how it was used with the old APIs. Every time a new measurement has been created, the app cosindered the old track as empty and, therefore, deleted the track. Took a lot of time to figure this out and to find a fix for that.

Next Tasks
  • Fixing a bug related the start of another new track without closing the application.
  • Text to speech function activating or deactivating in the settings.
  • Integrate somethin on the dashboard that indicates the track recording.
  • Show Car type info on dashboard.
  • Overhaul the Navigation Drawer.

Week 5 (22-28 June)

  • Continued implementing the background service that handles the auto-connection to the Bluetooth device.
  • The background service now periodically searches for the OBD adapter and the discovery interval can be set in the preferences.
  • Optimized some layout changes in the different list views and used the new APIs for these features.
  • Completely re-implemented the background service that establishes and handles the connection to the OBD device, because this class was full of dead code and was hard to understand.
  • Made more use of Otto for the implemented services.
  • Documented the newly implemented source code.

  • I had some problems related to background services running within a different process. Unfortunately, this service has its own scope and context, which makes it very complicated to handle. For this reason, I switched back to a bounded service within the same process.

Next Tasks
  • Finalize the service for auto-connecting with the OBDII adapter and its NotificationHandler.
  • Completely switch to Otto and remove the used version for dependency injection.

Week 4 (15-21 June)

  • Integrated a service that gets started on system specific events, e.g., when the device has been succesfully booted or when Bluetooth has been turned on.
  • The service searches periodically for the paired and selected OBDII adapter and, if it is successfully discovered, it automatically connects to the OBDII adpater and starts a track.
  • The service is implemented in a way that it is active only if Bluetooth is active.
  • Implemented a notification for the background service that on the one hand provides information about the current state of the service (e.g., whether it is unconnected, searching for other devices, or currently recording a track.) and on the other hand to provide direct interaction possibilities, e.g., start/stop track.
  • The notification is even shown when the application has been completly closed.
  • Code documentation.
  • Writing the mid-term blog article.
  • The service in general restarts every time when the app has been closed before and the service receives a system specific broadcast. The problem here is, that it restarts without any prior notifications (e.g., onDestroy()). This seems to be the intended design of services (see, for instance, here).
Next Tasks
  • The implemented service for handling the different automation aspects for the recording of tracks is only in a very early stage right now. There are still a lot of features and cases that have to be considered and implemented.
  • The device should be able to decide when a track is started and finished. This includes the integration of appropriate settings in the SettingsFragment.

Week 3 (8-14 June)

Stable commit can be found here.
  • Implemented a device discovery mechanism for the discovery of nearby Bluetooth devices.
  • Implemented the ability of pairing using reflection API in order to enable the device to initiate a pairing to previously discovered Bluetooth devices.
  • Removed the SettingsActivity and re-implemented a PerferenceFragment instead of the activity.
  • Re-implemented the preference for selecting the OBD device and improved the design of the preference.
  • Used the event bus of Otto to make the application more responsive to Bluetooth state changes (e.g., turning on the Bluetooth while remaining in the settings fragment will now enable the “Select OBD Device” button)
  • Further clean ups of the source code (i.e., removed dead code, removed generated layouts and styles that are not really important for the application, removed unused variables, added source code documentation, and many more…)
  • Documented the code of the new implementations.
  • Integrated all necessary strings as R.string.
Comparison of old (left) and new (right) general layout. Remember,

dashboard_old.jpg dashboard_new.png

navdrawer_old.jpg navdrawer_new.png

bt_selection_old.jpg bt_selection_new.png

Comparison of old (left) and new (right) settings

settings_old.jpg settings_new2.png

Two screenshots related to the bluetooth pairing.

new_pairing_1.png new_pairing_2.png

  • The “official” enviroCar colors make it hard to follow the material guide lines provided by google.

Next Tasks
  • Implement the ability of auto-connecting to paired OBD-Devices.
  • Re-implement the service that handles the bluetooth connection to the OBD device.
  • May start integrating the automated detection of track start/end points.
  • Clean up the code and keep trying to understand the undocumented code.

Week 2 (1-7 June)

  • Removed the notification handling from ECApplication into its own class called NotificationHandler, because the Android Application is not intended to do things like this!
  • Completely removed all (and this was a lot) static classes and integrated dependency injection with dagger instead. Static classes are not the way of designing applications for android, because they are able to survive outside the application lifecycle (e.g., when a crash occurs) and thus they can lead to unpredictable errors. My integration of dagger is designed based on different scopes (e.g., Application scope, Activity scope, Fragment scope) to overcome the limiting factors previously mentioned.
  • Completely re-implemented the ECApplication class, because this class was full of dead code and code that does not belong to this class.
  • Completely re-implemented the MainActivity class, because this class was full of dead code and unnecessary complicated use of variables (e.g., sometimes it used the activity context and sometimes the application context, sometimes it used static getInstance() while the variable is already locally available, sometimes it uses static getter for variables in the own class…)
  • Extended the DAOs to dynamic initialization and dependency injection.
  • Recently started implementing a complete new Service for handling the Bluetooth connections, because the old one is undocumented and quite difficult to understand, which makes it hard to simply extend with new functionalities

  • Code ignores many coding conventions for Android, and it is hard to find any logical structure.
  • Due to the lack of documentation and to the unstructured and distributed nature of single functionalities across multiple classes, it is quite hard for me to find entry points. Therefore, I first target some re-implementations.

Next Tasks
  • Continue implementing the new Android Service for bluetooth connection handling.
  • Integrate a discovery mechanism for devices with the possibility of pairing.
  • Implement an auto-connect to already paired devices.
  • Clean up the code and keep trying to understand the undocumented code.

Week 1 (25-31 May)

  • Set up the development environment and installed the necessary software.
  • Become familiar with the development environment and the source code of the enviroCar app.
  • Reading the source code in more detail to find entry points for the Bluetooth-related tasks to do.
  • Prepared a draft of the features to be implemented and ideas of features to be changed in the enviroCar app.
  • Migrated the application to Android Studio including Gradle as build development.
  • Integrated the newest version of the support package v7 for Android.
  • Completely removed the Actionbar Sherlock and integrated the Android Toolbar instead.
  • Raised the version of the app to be able to use new support packages.
  • None so far.
Next tasks
  • Discuss the list of ideas and features.
  • Integrate Dagger (Dependency Injection) and Otto (Eventbus) to simplify the development progress.
  • Start integrating a new service for the bluetooth discovery including autoconnect.
  • Slightly adjust the application to the new Material Design Standards.

Mid-Term Demo

The apk can be downloaded here.

Thinks you have to notice before:

  • When deinstalling the old and installing the new version, all of your local tracks get lost.
  • WARNING: When you want to use the old version, the be aware that you cannot simply deinstall the new and switch to the old version anymore. There is bug in the old and new application that does not allow you to install the same application from a different user. This will be fixed in the near future.
  • Note that this is not a 100% working app. It serves merely to get some impressions of the achieved work so far. Some of the original features are not working because of the migration to a newer Android version.

Instructions to install the app:

Before you can install the apk on your phone you will need to make sure that third-party apps are allowed to be installed on your device. This can be done as follows
  • Go to Menu -> Settings -> Security -> check "Unknown Sources" to allow the installation of apps other than the play store
If an old version of enviroCar has already been installed, then first uninstall it like follows.
  • Go to Menu -> Settings -> Apps
  • Click on the enviroCar app and then uninstall it.
To install the new apk you have to do the following:
  • Put the apk somewhere on your smartphone where you can find it.
  • Use, for instance, the Astro file manager to install the app
  • Install and start Astro and navigate to the place where you stored the apk.
  • Click on the apk and install it.
Topic attachments
I Attachment Action Size Date Who Comment
bt_selection_new.pngpng bt_selection_new.png manage 135 K 17 Jun 2015 - 12:10 ArneDeWall old bluetooth selection
bt_selection_old.jpgjpg bt_selection_old.jpg manage 50 K 17 Jun 2015 - 12:10 ArneDeWall old bluetooth selection
dashboard_new.pngpng dashboard_new.png manage 136 K 17 Jun 2015 - 12:10 ArneDeWall old bluetooth selection
dashboard_old.jpgjpg dashboard_old.jpg manage 26 K 17 Jun 2015 - 12:10 ArneDeWall old bluetooth selection
nav_drawer.pngpng nav_drawer.png manage 143 K 23 Jul 2015 - 19:23 ArneDeWall  
navdrawer_new.pngpng navdrawer_new.png manage 148 K 17 Jun 2015 - 12:11 ArneDeWall old bluetooth selection
navdrawer_old.jpgjpg navdrawer_old.jpg manage 34 K 17 Jun 2015 - 12:11 ArneDeWall old bluetooth selection
new_dashboard.pngpng new_dashboard.png manage 254 K 23 Jul 2015 - 19:23 ArneDeWall  
new_pairing_1.pngpng new_pairing_1.png manage 109 K 17 Jun 2015 - 12:11 ArneDeWall old bluetooth selection
new_pairing_2.pngpng new_pairing_2.png manage 105 K 17 Jun 2015 - 12:11 ArneDeWall old bluetooth selection
org.envirocar.app-debug-unaligned.apkapk org.envirocar.app-debug-unaligned.apk manage 4 MB 21 Aug 2015 - 08:12 ArneDeWall  
org.envirocar.app-debug.apkapk org.envirocar.app-debug.apk manage 4 MB 21 Aug 2015 - 08:12 ArneDeWall  
settings_new.pngpng settings_new.png manage 137 K 17 Jun 2015 - 12:11 ArneDeWall old bluetooth selection
settings_new2.pngpng settings_new2.png manage 138 K 17 Jun 2015 - 12:27 ArneDeWall  
settings_new_off.pngpng settings_new_off.png manage 116 K 17 Jun 2015 - 12:11 ArneDeWall old bluetooth selection
settings_old.jpgjpg settings_old.jpg manage 57 K 17 Jun 2015 - 12:11 ArneDeWall old bluetooth selection
track_cardview1.pngpng track_cardview1.png manage 1 MB 23 Jul 2015 - 19:23 ArneDeWall  
trackdetails_1.pngpng trackdetails_1.png manage 1 MB 23 Jul 2015 - 19:24 ArneDeWall  
trackdetails_2.pngpng trackdetails_2.png manage 772 K 23 Jul 2015 - 19:24 ArneDeWall  
trackdetails_3.pngpng trackdetails_3.png manage 154 K 23 Jul 2015 - 19:24 ArneDeWall  
Topic revision: r24 - 27 Jun 2016, UnknownUser
Legal Notice | Privacy Statement

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki? Send feedback