Take into account that Android is quite a weird OS that —even based on Linux— can’t be considered plain Unix. In fact, filesystem Unix owners should not be backed up because they are specific of the current installation. These users are generated automatically when installing an app, and have the form uX_aY where X marks the Android user ID and Y is the app ID, by installation order. (This is right from Android 4.4)
So, you’ll se the trouble with this example: if I, main Android user of my Android phone (u0), backup an app (e.g. a79) and then restore it in a secondary Android user (e.g. u2) of another phone with more apps installed (e.g. 100)… then folders and files will be assigned to a Unix user (u0_a79) that doesn’t match what it should (u2_a101), opening up a door for potential security vulnerabilities (or, more probably because of SELinux/SEAndroid, instabilities and crashes).
TL;DR: Unix users for app data should be calculated at restore-time because they are generated at install-time depending of the system state.
Unix groups are permission-dependant, so same thing: should be calculated at restore-time.
App backup are a pretty hard thing to implement right because of platform architecture changes between Android versions and portability. That’s why some solutions use specific formats (like Titanium Backup) or append a manifest/log (like Oandbackup), IMO.