Plain GPS based recording for enviroCar


Currently, the Android application for enviroCar can record tracks only when it is connected to the OBD-II adapter through Bluetooth. The enviroCar app will be of no use to the user if the user does not have a working OBD-II adapter or if Bluetooth is not working in the user’s mobile phone. This limits the usage of the app to a great extent. The main goal of this project is to add plain GPS based recording of a track in the enviroCar Android application. This will increase the usability of the enviroCar app and simultaneously increase the collection of data in the enviroCar server, which can be used to analyze traffic. It is also equally important to automate the GPS-based track, for which Activity Recognition features can be used. UI/UX of the app will also be improved as per the proposed designs (which can be found here).

About Me

My name is Sai Krishna Chowrigari, an undergraduate student studying Dual Degree (B.Tech. + M.Tech.) Computer Science and Engineering in Indian Institute of Technology (ISM), Dhanbad, India. I have two years of experience in Android app development and I am a newbie to Open Source. You can follow the project development work on Github.

Github repository: https://github.com/enviroCar/enviroCar-app

My contributions: https://github.com/enviroCar/enviroCar-app/pulls?utf8=%E2%9C%93&q=+author%3ASaiKrishna1827+

As part of the GSoC, I have created 3 blog posts, each at different point of time of the project, which are as follows:

Introductory blog post: https://blog.52north.org/2018/05/23/plain-gps-based-recording-for-envirocar-introductory-blog-post/

Midterm blog post : https://blog.52north.org/2018/07/06/plain-gps-based-recording-for-envirocar-mid-term-blog-post/

Final blog post : will be added soon.

Weekly Reports

Week 01

Status
  • Got familiar with the existing code base.
  • Updated the following libraries (see PR #325 on GitHub)
    • Dagger 1 to Dagger 2
    • Butterknife from com.jakewharton:butterknife:6.1.0 to com.jakewharton:butterknife:8.8.1
    • Gradle version from 2.10 to 4.4 (latest)
    • targetSdkVersion from 23 to 27 (latest)
    • buildToolsVersion from 23.0.2 to 27.0.3 (latest)
    • All Android Support libraries version from 23.2.0 to 27.1.1 (latest)
  • Removed Retrolambda library as lambda expressions are supported by the current environment used (which is Java 8).

Problems
  • Static injections are supported in Dagger 1 but not in Dagger 2. So this helped me in solving the issue.
  • Injections in Generics classes troubled me a bit. But this came to the rescue.

Next Steps
  • Design a new dashboard view.
  • Remove the navigation drawer, embed bottom bar in place of it and associate all the activities/fragments to it.

Week 02

Status
  • Completed new Dashboard design.
  • Completed designing new "My Tracks" and "Others" views and also completed giving functionality to them.
  • Completed integration of bottom bar with all the activities/fragments.

Problems
  • No problems.

Next Steps
  • Design new Track Recording screen.
  • Complete the functionality of recording screen and dashboard

All the designs can be accessed here.

Week 03

Status
  • Completed designing new Track recording screen.
  • Completed giving functionality to the newly designed dashboard and track recording screen for existing OBD based recording.
  • Removed bugs in the automatic OBD based track recording.
  • Moved the OBD recording service to the foreground, to remove the GPS issues in new Android versions.
  • Removed the existing custom notifications and introduced new default android notifications.

Problems
  • No problems.

Next Steps
  • Complete the GPS based recording service.

All the designs can be accessed here.

Week 04

Status
  • Completed building the Service for GPS Only track recording.
  • Designed recording screen for GPS based track recording. (link)

Problems
  • No problems.

Next Steps
  • Complete integrating the GPS Only track recording service into the app.

Week 05

Status
  • Completed integrating the GPS Only track recording service into the app. (link)
  • Removed some bugs and implemented some changes proposed by the mentor.

Problems
  • No problems.

Next Steps
  • Design custom notifications, which should display time, speed, distance traveled, while recording the track.

Week 06

  • Took a week Off.

Week 07

Status
  • Cleared the bugs present in logging the data. Details are as follows: After updating the target SDK to the one > 22, runtime permissions were introduced in android. So for logging the data, the enviroCar app wants the storage permission, which we are asking on clicking "Report Issue". So logging is taking place only for the time after the user granted the storage permission. So now I have implemented the routine which asks storage permission to the user at the starting of the app, by giving a proper explanation.
  • Cleared the bug present in tracklist fragment: Details are as follows: On clicking "export track" in the tracklist fragment, android.os.FileUriExposedException is encountered. This error occurs as we are trying to share a file:// Uri in an Intent broadcast to share data with other apps. As of Android N, we need to use the FileProvider API.
  • Removed many unused strings and drawables from the repository, which decreased the APK size by 0.63 MB.
  • While the track recording is in progress, details of the track like distance traveled, the time taken and average speed were displayed in the notification itself, so that user can see them without opening the app. It looks like :

Problems
  • Chronometer in custom notification did not work as expected in some versions of Android. By going deeper into the functionality of notification and chronometer, I solved it.

Next Steps
  • Design and implement multiple tempomat view to display multiple live readings in the app, while the track recording is in progress.
  • Go through the activity recognition libraries and experiment them to select a library which is most efficient and reliable for our use case.

Week 08

Status
  • Went through many blogs and websites and found that the most suitable activity recognition library to be used in our use case is Activity Transition API, as discussed earlier.
  • Made a sample app to test the reliability and find the average latency of the Activity Transition API.
  • After testing the API with up to 40-50 measurements in 4 mobile phones, it is decided to use the API as it is reliable enough for our use case.
  • Average latency of the API is found to be 55 sec. All the recordings recorded while testing can be found here.

Problems
  • I was not able to design a perfect layout for the multiple recordings view. I stopped working on it as it took a lot of time. I will start fresh in the next week, and try to improve it further.

Next Steps
  • Embed Activity Transition API into the GPS based track recording.
  • Complete designing the screenshots for the marketplace in the play store.

Week 09

Status
  • Embedded Activity Transition API in GPS based track recording, which verifies whether the track is started while driving or not. Now, GPS based tracks will be started only when the user is traveling on any vehicle. The track will not be started until it detects that the user is ON_VEHICLE.
  • Apart from some small editings, completed designing the screenshots for the marketplace in the play store.

Problems
  • No problems

Next Steps
  • Complete the embedding of auto-connect settings for the GPS based track recording.
  • Stop the track after 2*(average latency) seconds, after detecting that user is not ON_VEHICLE.

Week 10

Status
  • GPS-based tracks will be stopped automatically after 2*55 sec of detecting not ON_VEHICLE automatically. However, it can also be stopped manually.
  • Autoconnect settings were partially embedded into the application.
  • Completed designing the screenshots for the marketplace in the play store. All the designs can be accessed here.

Problems
  • No problems

Next Steps
  • Complete the embedding of auto-connect settings for the GPS based track recording.
  • Cut the GPS track accordingly, whenever it is automatically stopped because of the detection of not ON_VEHICLE.

Week 11

Status
  • Autoconnect settings were implemented for GPS based tracks.
  • Now GPS based tracks will be trimmed, when the track is automatically stopped because of the detection of not ON_VEHICLE. (link)

Problems
  • No problems

Next Steps
  • Increase the frequency of GPS updates, so that more accurate GPS values will be displayed to the user.
  • Combine Automatic GPS Service and Automatic OBD Service into one.
  • Make GPS track recording optional, by placing a preference to opt in/out for the GPS based tracks.

Week 12

Status
  • Combined Automatic GPS service and Automatic OBD service into one service, so that user can operate the app easily. (link)
  • Made the GPS based track recording optional, by placing a preference to opt in/out for the GPS based tracks. GPS based track recording is an optional and a beta feature now. (link)
  • Made some UI adjustments in GPS based track recording. (link)
  • Restricted uploading of GPS based track into the server. (link)

Problems
  • No problems

Next Steps
  • Code cleanup.
Topic revision: r14 - 15 Aug 2018, SaiKrishnaChowrigari
Legal Notice | Privacy Statement


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