Auto Rickshaw Fare Estimator Android App with City Meter Rates and Trip History

A passenger standing at an auto stand usually has no reliable figure for what the ride should cost. The driver quotes a lump sum, the passenger guesses from past rides, and the disagreement surfaces only at the destination, when one side feels overcharged and the other feels short-changed. Meter readings do not settle it either, because the passenger cannot see the rate card behind the reading, cannot check whether a night surcharge applies, and has no record of what previous comparable trips cost. The result is a small, repeated, everyday dispute that neither side can prove.

This is a built-to-order software project: the Android app, rate-card editor, trip history, report, abstract and presentation slides are built fresh for each order.

The Auto Rickshaw Fare Estimator Android App with City Meter Rates and Trip History answers that dispute with a checkable figure before boarding. The passenger picks a city rate card, enters the trip distance and any expected waiting time, and the app returns an estimated fare with its full break-up: base fare, distance charge, waiting charge and any night surcharge, each a separate line. If the ride is shared, the same screen splits the estimate between passengers. Because the rate cards are saved on the device, the estimate works at an auto stand with no mobile data, and every estimate can be stored in a trip history that records the route, the city card used and the split, so the next similar trip starts from a real earlier figure, not a guess. The figure is always labelled an estimate; the meter reading at the end of the ride is the final fare.

The Auto Rickshaw Fare Estimator Android App with City Meter Rates and Trip History runs as one short flow from card to saved trip. The user first opens the rate-card screen and checks the card for the city of travel, editing any changed rate. On the estimate screen the user picks that city, enters the trip distance and expected waiting time, sets the passenger count and night hours for rides between 11 pm and 5 am. The app then applies the card's rules in order: base fare for the included kilometres, per-kilometre rate for the distance beyond them, waiting rate for the waiting minutes, and the night surcharge percentage on the subtotal when night hours are on. The result appears as a broken-down estimate with the split beside it, and the user can save the trip to on-device history, so the next similar trip can be checked against a real earlier figure offline.

1. The user opens the rate-card screen and checks the card for the city of travel, editing the base fare, per-kilometre rate, waiting rate or night surcharge if any rate has changed.
2. On the estimate screen the user picks the city card, enters the trip distance in kilometres and the expected waiting time in minutes.
3. The user sets the number of passengers sharing the ride and switches night hours on when the ride falls between 11 pm and 5 am.
4. The app applies the card's base fare for the included kilometres, then charges the per-kilometre rate for the distance beyond them.
5. Waiting minutes are charged at the card's per-minute rate, and the night surcharge percentage is applied to the subtotal when night hours are on.
6. The estimate is shown with its full break-up, base fare, distance charge, waiting charge and night surcharge as separate lines, with the fare-split beside the unchanged total.
7. The user saves the trip to the on-device history with its route, city card and split, and the saved record remains available offline for the next similar trip.

Tech stack:

• Kotlin · Android app development
• Android Studio · app build and layout editor
• Jetpack Compose · declarative Android UI
• Room database · on-device trip history storage
• SharedPreferences · saved city rate cards
• Material Design 3 · app theme and components
• JUnit · unit tests for fare calculation
• Git · source version control

The Auto Rickshaw Fare Estimator Android App with City Meter Rates and Trip History is built around four capabilities that carry the whole experience. Editable city rate cards let the user store and change the base fare, per-kilometre rate, waiting rate and night surcharge for each city, so the estimate follows the rates the user actually travels under instead of one fixed table. The fare estimate itself takes a distance and waiting time and returns a broken-down figure, with a night-hours toggle that applies the surcharge rule visibly rather than hiding it inside the total. Fare-split divides the estimate between up to four passengers and shows each share beside the unchanged total. Trip history saves each estimate with its route, city card and split, and because all of it lives on the device, the app keeps working offline at an auto stand with no mobile data.

• [Editable city rate cards] The user can add or change a city's base fare, per-kilometre rate, waiting rate and night surcharge, and the saved card is used for every later estimate in that city. Implemented in the base build.
• [Fare estimate with break-up] Distance and waiting time produce an estimate shown as separate lines for base fare, distance charge, waiting charge and night surcharge, so the passenger can see exactly which rule produced each rupee. Implemented in the base build.
• [Night and waiting surcharge rules] A night-hours toggle applies the card's night surcharge percentage to the subtotal, and waiting minutes are charged at the card's per-minute rate, both shown as their own lines in the break-up. Implemented in the base build.
• [Fare-split for shared rides] The estimate divides between up to four passengers, showing each person's share next to the unchanged total, so a shared ride can be settled before boarding. Implemented in the base build.
• [Offline trip history] Every estimate can be saved with its route, city card, distance, waiting time and split, and the history stays on the device, so past trips can be checked at an auto stand without mobile data. Implemented in the base build.
• [Rounding rule for split fares] Builder note from the demo build: rounding a split fare to whole rupees can push the sum of the shares Re 1 above the total, for example Rs 153 split two ways shows Rs 77 each, totalling Rs 154, so the demo always shows the true total beside the per-person figure and never adjusts the total to fit the split. Implemented in the base build.
• [Estimate-only labelling] Every fare figure in the app carries the word estimated, and the screen states that the meter reading at the end of the ride is the final fare, so the estimate is never presented as a bill. Implemented in the base build.

Optional and future scope (not in the base build): live GPS distance capture, official city rate updates from a server, route search with distance lookup, ride receipt sharing, and multi-language screens. These can be developed on request and are not claimed as included.

• Working Android app with estimate screen, rate-card editor, fare-split and on-device trip history
• Complete Kotlin source code with the fare calculation, surcharge rules and history storage
• Demo rate cards for six Indian cities with editable values
• Setup guide covering Android Studio build, install on a device and first estimate
• Project report covering background, working, fare rules, limitations and testing
• Project abstract PDF with 10 labelled sections matching this page
• Presentation slides for final review
• Viva Q&A preparation document covering Android storage, fare-rule design and offline behaviour