| I worked as a contractor at Parkeon/Flowbird, on the next version. IIRC, this one is called N² and runs a headless Android on a limited hardware, which explains the slowness of this thing. The next version (called streetsmart) on which I worked 2 years ago is a real mess. It is based on Android 5.1 (Android 8 or 9 was available when the project started), and features a touch screen. There is absolutely no isolation between ticketing apps and maintenance apps (which allow among other things to withdraw the cash). A custom launcher gives access to one set of apps or another, depending on the current mode. An hardware token and a gesture allow agents to switch from vending mode to maintenance mode, but if one gains access to a shell, one just has to send particular intents to access to maintenance apps. Some anecdotes: - We shipped debug Android builds for internal testing (with root, adb enabled, etc) which somehow got sent to the customer, deployed on a public network and got infected by crypto miners. That triggered overheat of the CPU and reboots of the devices. - Those are supposed to be deployed in Barcelona, I don't know if it's actually in production right now. - Those were supposed to be deployed in NYC, but the deal got cancelled (not really a surprise to me). - They run on a 12v car battery and a solar cell. I had a partial machine to dev (with no solar part), and I had to buy a car battery charger to power the battery. The work itself was rather interesting (have you ever worked on a Android device that has a built-in printer and a cash machine?), but project management, collaboration between teams and vision were terrible. The main board seemed really well designed also. |
Does it? Must be very limited hardware, then. I haven’t even ever seen one of those, but I would think a parking meter UI wouldn’t be particularly taxing on hardware.