Get app name and hook at runtime

Plarde

Is it possible, when developing a non-Qt app, to obtain some information about the current app, such as the "name" as written in manifest.json (like appname.yourname), as well as the name of the hook that launched the executable? (Excluding hardcoding them in the executable, of course)

I'm thinking something like environment variables. I've seen variables like APP_ID which seem to be derived from the app name and the hook, but I haven't seen anything like APP_NAME or APP_HOOK that correspond exactly to the fields I need.

My situation is that I'm porting SDL3 to Ubuntu Touch, and the app name and hook are needed to perform certain operations on Ubuntu Touch. Since SDL3 is a library, it can't make some presumptions about the executable.

developerbayman

@Plarde Yes, it is possible — though not entirely straightforward — to infer some runtime information like the app's name and the hook that launched it on Ubuntu Touch, particularly if the app is deployed as a click package.

Here’s a breakdown of your goals and possible solutions:
Goal: Get the App ID or Name from Manifest

In Ubuntu Touch click packages, metadata is defined in a manifest.json file, which contains fields like:

{
"name": "appname.yourname",
"version": "1.0.0",
"framework": "ubuntu-sdk-20.04",
...
}

How to get this at runtime?

At runtime, this data isn’t directly exposed via traditional environment variables like APP_NAME. However:

Environment Variables Available at Runtime: The AppArmor profile and the Ubuntu Touch application launch mechanism set a number of environment variables, including:

    APP_ID: Often the full app name like appname.yourname

    APP_PATH: The full installation path to the app

    APP_BIN: The binary or hook name

You can access these using C/C++/SDL via getenv("APP_ID"), etc.
Goal: Get the Hook Name (i.e., the launcher binary name)

Click packages specify "hooks" (executables, wrappers, or scripts) in the manifest.json under "hooks":

"hooks": {
"myhook": {
"apparmor": "myhook.apparmor",
"desktop": "myhook.desktop"
}
}

How to get the hook at runtime?

There’s no standard variable like APP_HOOK, but you can infer it from:

argv[0] or /proc/self/exe:

#include <unistd.h>
#include <limits.h>

char path[PATH_MAX];
ssize_t len = readlink("/proc/self/exe", path, sizeof(path)-1);
if (len != -1) {
    path[len] = '\0';
    printf("Executable Path: %s\n", path);
}

Then extract the final component to get the executable name — likely the hook.

Summary of Techniques
What You Want How to Get It
App ID (from manifest) getenv("APP_ID") or getenv("APP_NAME") (test both)
App Install Path getenv("APP_PATH")
Executable Name / Hook Use argv[0] or resolve /proc/self/exe
Manifest Contents Parse /opt/click.ubuntu.com/<appid>/manifest.json manually
Bonus: Parsing the Manifest Programmatically

If you want full manifest access:

#include <stdio.h>
#include <stdlib.h>
#include <json-c/json.h>

void print_manifest_field(const char* field) {
const char* appid = getenv("APP_ID");
if (!appid) return;

char manifest_path[512];
snprintf(manifest_path, sizeof(manifest_path),
         "/opt/click.ubuntu.com/%s/current/manifest.json", appid);

FILE* file = fopen(manifest_path, "r");
if (!file) return;

struct json_object *parsed_json;
parsed_json = json_object_from_file(manifest_path);
if (parsed_json) {
    struct json_object *value;
    if (json_object_object_get_ex(parsed_json, field, &value)) {
        printf("%s: %s\n", field, json_object_get_string(value));
    }
    json_object_put(parsed_json);
}

fclose(file);

}

️ Caveats

These variables are set by the Ubuntu Touch application launcher, so they only exist in the app context.

Hook names are not exported as a separate variable unless the launcher sets one explicitly.

SDL3 libraries should allow injection or configuration of these values from the hosting application (e.g., via init).

Final Advice for SDL3 Porting

Since SDL3 is a library and shouldn't hardcode values:

Consider requiring the host app to pass APP_ID and HOOK_NAME to SDL3 during initialization.

You could fallback to the environment and /proc/self/exe as a best-effort fallback.

Let me know if you want a ready-made SDL3-compatible utility wrapper function for this.