Apartment Parking Android App with Slot Allotment, Resident Permits and Guest Passes

The Apartment Parking Android App replaces the register book and the WhatsApp message thread that most housing societies still use to manage basement parking. In a typical society, slots are allotted by memory, a second car quietly takes a neighbour's bay, and a guest vehicle stays parked days after the visit ended because nobody recorded when the visit was supposed to end. This project answers that problem with one shared record: a slot map that shows every bay as free or allotted, a resident permit that binds one vehicle to one flat and one slot, and a guest pass that carries its own expiry window. Requests pass through an admin approval queue, so allotment is a decision with a name and a timestamp attached, not a favour granted in a corridor conversation. The demo built for this listing models 40 bays: a 36-slot basement with 14 free bays and 22 allotted bays, plus 4 visitor bays.

The mechanism is deliberately boring in the best sense: every parking right in the building exists as exactly one record with a status, and every status change passes through the admin queue. A resident never edits the slot map directly; they request, and the admin approves. A guest never holds a permanent right; they hold a pass with an end time, and expiry is enforced by comparing the current time with that end time at the gate, not by hoping someone remembers to delete the pass. That single rule — rights are records, records have statuses, statuses change only through approval or expiry — is what keeps two residents from holding the same bay and what keeps a weekend guest from becoming a permanent parker. The admin queue is the only path between a request and a right, and the gate check is the only path between a pass and entry.

1. The resident opens the app, sees the basement slot map with free and allotted bays, and taps a free bay to select it.
2. The resident submits an allotment request, which records the flat number, vehicle plate and requested bay, and appears in the admin queue as pending.
3. The admin reviews the queue, checks that the bay is still free and the flat holds no conflicting allotment, then approves or rejects the request.
4. On approval, the system creates a digital resident permit binding the flat, the vehicle and the bay, with a 12-month validity (design target) and the bay marked allotted on the map.
5. For a visitor, the resident fills in the guest name, plate, visiting flat and visit window, and the app generates a guest pass with a unique pass code and a visitor-bay assignment.
6. At the gate, the guard checks the pass code against the visitor name, plate and flat, and admits the vehicle only while the pass is valid and unrevoked.
7. When the visit window ends, the pass expires automatically; the admin can also revoke an issued pass early, and a revoked or expired pass is refused at the gate.
8. Permit renewal repeats the same queue: the resident requests renewal, the admin approves, and the permit validity extends without re-allotting the bay.

Tech stack:

• Kotlin · Android Studio
• Jetpack Compose UI
• Firebase Authentication
• Cloud Firestore database
• Firebase Cloud Messaging
• QR code generation library
• MVVM architecture
• Git version control

The app's three capabilities work as one system rather than three separate tools: the slot map is the single source of truth for which bays are free, the resident permit turns an approved allotment into a checkable record, and the guest pass extends the same discipline to visitors without giving them permanent access. Around those three, the admin queue, the gate check and the pass-expiry rule close the loopholes that make manual parking management break down: a request cannot silently become an allotment, a pass cannot silently become permanent, and a revoked pass cannot be reused. The demo shows all three views working together — a resident requesting bay A-104, a guest pass for Flat B-305 with a four-hour window, and an admin queue holding two pending decisions — so the viva discussion can trace one request from tap to approval.

• [Live slot map] A basement-level grid shows every bay as free, allotted or selected, with counts for each state, so a resident checks availability before requesting instead of asking the office.
• [Slot allotment requests] A resident taps a free bay and submits a request tied to their flat and vehicle; the bay stays marked as requested, never silently reserved, until the admin decides.
• [Digital resident permits] Each approved allotment creates a permit record naming the flat, the vehicle plate and the slot, with a 12-month validity (design target) that the admin renews or ends.
• [Time-limited guest passes] A resident generates a pass for a named visitor, vehicle plate and visit window; the pass stops working when its window ends, without anyone needing to cancel it.
• [Admin approval queue] Allotment requests, permit renewals and guest passes land in one queue where the admin approves, rejects or revokes, and every decision updates the resident view immediately.
• [Gate check view] The guard checks a pass by its code, visitor name, plate and flat, and sees its validity at a glance, so an expired or revoked pass is refused at the gate.
• [Visitor bay separation] Guest vehicles are directed to dedicated visitor bays, keeping resident bays out of the visitor flow and making overstays visible in one place.

• Complete Android app source code (resident, admin and guard flows)
• Slot map, allotment request and approval queue implementation
• Guest-pass generation with pass codes and expiry handling
• Demo dataset with 36 basement slots plus 4 visitor bays, permits and pending requests
• Project report PDF (background, system design, database schema, methodology, testing)
• PPT presentation for final review
• Viva Q&A preparation document (Android architecture, Firebase data modelling, role-based access, expiry logic)