Step 1) You are going to need to determine how much control you can have over the phone itself.
Step 2) Clarify reasonable assumptions. Can you assume you know when the person is actually supposed to be driving? At the time, before hand, or only after the fact? This ties in to...
Step 3) Can the user of the app be individually identified - is it registered to a known person's identity/phone?
Depending on these answers, you have a variety of tools from the phone at your disposal - or do you?
- Clock
- GPS
- internet connection
- truck/car mounted equipment that can be communicated with
The best solution for a situation where you have a known driver, a set schedule, and a phone where you have access to time, GPS, and reasonable internet, would use a combination.
You might first get a driver schedule for the day, and use it to determine when a driver should be working. You can then use the GPS (or vehicle equipment) to determine movement beyond human walking (anything over 10-20mph would be pretty obviously "not walking"), and if this is within a time period the person should not be driving you either refuse use of the app, and preferably report it to the company for human inspection with applicable information.
If you have vehicle equipment, when the vehicle is not parked the phone/app cannot be used. Even easier!
Each individual thing has human failings or is easy to beat - a person can just say they aren't working, falsify or not enter a work schedule, turn GPS off to hide their movement, not install this app on their own phone or use a second one, etc. But if it is combined with a company system that can combine documentation, and the company takes this as seriously as they should, then you have a hybrid solution that combines all available knowledge.
"You were tooling around with your phone while you were scheduled to be driving, and were in fact actually driving. If this happens again you will no longer be employed with us."
If this is just a casual or non-mandatory app, then obviously many of these solutions won't suit your use case at all - but this is precisely why the use case must be clearly defined so you know what tools you have available to solve your problem.