Offline Bus Timetable and Route Tracking Android App for Rural Routes with Stop Alerts

What problem does a rural bus passenger face?
The Offline Bus Timetable and Route Tracking Android App for Rural Routes with Stop Alerts is built for a passenger who cannot check a rural bus time online before leaving home. The problem is not that rural buses have no timetable at all, but that the timetable is rarely where the passenger is when the decision is made. Printed sheets stay at the stand and enquiry numbers go unanswered, so a passenger guesses the departure and waits through a long gap between buses. On the bus, stops are not always announced, landmarks look alike after dark, and a first-time passenger can ride straight past the stop they needed. An app that only shows a timetable online does not solve either half, because the moments that matter are the moments when a connection is weakest. The app treats offline access as the core requirement, and pairs a saved timetable with a stop alert that works from the phone's position.

On many rural routes, the timetable lives on a printed sheet at a bus stand, in a driver's memory, or not anywhere a passenger can check from home. A passenger who misses one bus may wait for hours for the next, and a passenger travelling an unfamiliar route may miss a stop simply because nobody announced it. This app moves the timetable onto the passenger's phone and keeps it there, so the information is available at home, at the stop, and on the bus, even where mobile data is weak or absent.

Tech stack:

• Kotlin · Android application
• Android Room database · local timetable storage
• Android GPS location · journey position matching
• Android notifications · stop alerts
• Material Design components · app interface
• JSON timetable bundle · operator data import
• Git · version control

What can this app actually do for a passenger?
The Offline Bus Timetable and Route Tracking Android App for Rural Routes with Stop Alerts is built around four capabilities a passenger can use on a real journey: a timetable saved on the phone that needs no connection, a next-departure answer for the route being checked, a stop alert that warns before the passenger's stop, and a journey view that shows where the bus is along the route. Around those four capabilities, the app adds route search and saved favourite routes, so a daily commuter reaches a familiar route quickly, and an operator-side timetable editor, so saved times can be corrected without rebuilding the app. Every feature below is part of the base app unless marked optional or future scope, and a demonstration can show an offline timetable, a next departure, a set alert, and a journey moving stop by stop, all without mobile data.

• [Offline timetable bundle] The full timetable for each route, including stop names, stop order, and departure times, is stored on the phone when the app is installed, so routes, timetables, and arrival times open with no mobile data and no waiting for a server. Implemented in the base app.
• [Next-departure lookup] The app compares the current time on the phone with the saved departures for the chosen route and shows the next bus, plus the first bus and last bus of the day, so a passenger can decide at a glance whether to hurry or wait. Implemented in the base app.
• [Stop alerts] A passenger taps the bell beside a stop, and the app sounds an alert 2 stops before that stop and again at the stop before it, giving time to gather luggage and move towards the door instead of a last-second rush. Implemented in the base app.
• [Journey progress view] During a journey the app shows the current stop, the next stop, and progress along the route, so a passenger can see how far along the route the bus has travelled without asking fellow passengers. Implemented in the base app.
• [Route search and favourite routes] Passengers search by village, town, or route number, and star a route to save it as a favourite, so a daily route opens from the favourites list instead of a fresh search each morning. Implemented in the base app.
• [Operator timetable editor] An editor screen lets the route operator correct a departure time, add a stop, or add a route, and the change is saved to the on-phone timetable bundle, so timetable corrections do not need a new app release. Implemented in the base app.
• [Timetable update pack] When the phone is briefly online, the app can import a timetable update file supplied by the operator, replacing the old bundle with the new one, so seasonal or revised timetables reach passengers without reinstalling the app. Optional extension, not included in the base app.
• [Live bus location sharing] If buses later carry a location-sharing device, the app could show a live bus position on the route in a future version, turning the timetable view into a live tracking view. Future scope only, not implemented and not included in the base app.

How does the offline timetable and stop alert actually work?
The chain starts with timetable data saved on the phone at install time: each route carries its stop names in order, the minutes from departure to each stop, and the departure times for the day, all stored in the app's local database. When a passenger opens a route, the app computes arrival times by adding each stop's minute offset to the chosen departure time, and it finds the next departure by comparing the phone clock with the saved departure list. During a journey, the phone's GPS position is matched against the saved stop coordinates in route order, and the app advances its current-stop marker as the bus passes each stop. When the current stop is 2 stops before the passenger's alert stop, the app sounds the first alert, and it sounds again at the stop before, so the warning follows the bus's position rather than a clock estimate that a delayed bus would break.

1. The operator's route data, including stop names, stop order, minute offsets, departure times, and stop coordinates, is stored in the app's local database at install time.
2. The passenger searches by village, town, or route number, or opens a saved favourite route, and the app loads that route's saved timetable from local storage.
3. The passenger picks a departure, and the app computes each stop's arrival time by adding the stop's minute offset to that departure time.
4. The passenger taps the bell beside a stop, and the app saves that stop as an alert stop for the journey.
5. During the journey, the phone's GPS position is matched in route order against the saved stop coordinates, and the journey view advances stop by stop.
6. When the current stop is 2 stops before the alert stop, the app sounds the first alert, and it sounds again at the stop before the alert stop.
7. At the end of the journey the passenger can clear the alert, keep the route as a favourite, or set a new alert for the return journey.

The Concept
The concept is deliberately simple: a timetable is only useful if it is present at the moment of decision, and a stop alert is only useful if it is tied to where the bus actually is. The app therefore pairs a saved timetable with position-based stop counting, so neither part depends on a mobile data connection during the journey.

• Android app source code in Kotlin, with route list, timetable view, next-departure lookup, stop alerts, journey progress view, favourites, and operator timetable editor
• Sample timetable bundle with 4 routes, 22 stops, and 20 departures, ready to replace with the operator's real route data
• Single-file working web demo of the app interface, showing the route list, timetable view, and stop-alert journey view
• User manual for passengers and a separate operator guide for editing timetables and preparing an update file
• Project report PDF (background, system design, local database design, alert logic, limitations)
• PPT presentation for final review
• Viva Q&A preparation document (offline storage, GPS matching, alert logic, timetable editing, limitations)
• Builder note: the alert logic in this build counts stops, not minutes, so a delayed bus still alerts at the right stop, and that choice was settled during the demo build rather than assumed afterwards — the demo journey advances stop by stop, the alert fires 2 stops before the chosen stop, and the same counting rule drives the delivered Android app, with GPS matching replacing the demo's tap-to-advance simulation. The demo bundle as built contains 4 routes, 22 stops, and 20 departures in a single file of approximately 8.7 KB, which is why the whole timetable opens instantly with no connection.

Requirements

• An Android phone running Android version 8.0 or later, with GPS switched on during a journey for position-based alerts
• Approximately 15 MB of free storage space on the phone for the installed app (expected)
• Route data from the operator before release: route numbers, stop names in order, departure times, minute offsets between stops, and stop coordinates
• A computer with Android Studio for building the app from source, and a phone or emulator for testing the journey view
• No mobile data connection is needed during a journey; a brief connection is needed only for the optional timetable update pack

Timeline

• Week 1 covers route data design, the local database schema, and the route list and timetable screens
• Week 2 covers next-departure lookup, favourites, search, and the operator timetable editor
• Week 3 covers GPS journey matching, the journey progress view, and the stop-alert logic
• Week 4 covers the sample timetable bundle, the web demo, and end-to-end testing on a phone
• Week 5 covers the report, PPT, user manual, operator guide, and viva Q&A document
• Week 6 covers final testing, fixes, and delivery of the source code and documents

Support

• 30 days of bug-fix support after delivery for faults in the delivered app source, counted from the delivery date
• Guidance on replacing the sample timetable bundle with the operator's real route data during the support period
• One round of timetable-data corrections in the sample bundle during the support period, if the operator supplies corrected times