Regarding @{HOME}/.cache/Qt Project/QtQmlViewer, yes that is a bug that like you said, should solve this.
As for an API to find APP_PKGNAME, apps themselves can do it by accessing applicationName presumably or some other method that the developer can choose.
Correct me if I'm wrong, but I think your question is more about services for apps, like the content-hub. This is all very service specific, but in general you cannot trust what the application gives you and the only thing you can trust is the security label for the process which you can get via a libapparmor C call or over DBus (as mentioned). This label provides you with the profile name, which on Ubuntu will is the APP_ID for confined processes that come from click packages. While I think it might be a useful improvement to have some sort of a click library that could be used to give various information, we *must* always use the security label from the kernel if there are any security implications or decisions (like where to read or write a file).
Also keep in mind going forward, there are non-click confined processes and there are also unconfined processes which both become more relevant on the converged device. Unity8 will have the concept of APP_ID because of application lifecycle, but other desktop environments will not (perhaps that will be ported to Unity7). There is work to be done in this area.
Regarding @{HOME}/.cache/Qt Project/ QtQmlViewer, yes that is a bug that like you said, should solve this.
As for an API to find APP_PKGNAME, apps themselves can do it by accessing applicationName presumably or some other method that the developer can choose.
Correct me if I'm wrong, but I think your question is more about services for apps, like the content-hub. This is all very service specific, but in general you cannot trust what the application gives you and the only thing you can trust is the security label for the process which you can get via a libapparmor C call or over DBus (as mentioned). This label provides you with the profile name, which on Ubuntu will is the APP_ID for confined processes that come from click packages. While I think it might be a useful improvement to have some sort of a click library that could be used to give various information, we *must* always use the security label from the kernel if there are any security implications or decisions (like where to read or write a file).
Also keep in mind going forward, there are non-click confined processes and there are also unconfined processes which both become more relevant on the converged device. Unity8 will have the concept of APP_ID because of application lifecycle, but other desktop environments will not (perhaps that will be ported to Unity7). There is work to be done in this area.