English | 简体中文
browser-cpp-demo is a standalone C++ reference project for the BroSDK native C/C++ SDK. It demonstrates how to dynamically load brosdk.dll / brosdk.so / brosdk.dylib, register the global asynchronous callback, and call the main native APIs exposed by brosdk.h.
This project is intended for developers who need to integrate BroSDK directly into C++ desktop clients, automation tools, test programs, or internal systems.
- Demonstrate cross-platform dynamic loading of the BroSDK native runtime.
- Register the global
sdk_register_result_cbasynchronous callback before initialization. - Demonstrate APIs such as
sdk_init,sdk_info,sdk_browser_open,sdk_browser_close,sdk_env_*,sdk_token_update, andsdk_shutdown. - Show the difference between asynchronous task acceptance and final browser lifecycle events.
- Support both interactive command-line mode and one-shot command mode.
- Use JSON files for complex initialization, launch, close, and environment management requests.
browser-cpp-demo/
├── 3rdparty/
│ ├── brosdk/
│ │ ├── brosdk.h
│ │ └── brosdk.dll / brosdk.so / brosdk.dylib
│ ├── dlfcn-win32/
│ └── rapidjson/
├── examples/
│ ├── init.json
│ ├── open.json
│ ├── close.json
│ ├── token-update.json
│ └── env-page.json
├── src/
│ ├── main.cc
│ ├── sdk_wrapper.h
│ ├── sdk_wrapper.cc
│ ├── utils.h
│ └── utils.cc
├── CMakeLists.txt
├── LICENSE
├── README.md
└── README_EN.md
| Item | Requirement |
|---|---|
| CMake | 3.16+ |
| C++ | C++20 |
| Windows | Visual Studio 2019+ or a compatible MSVC toolchain |
| macOS / Linux | Clang or GCC with C++20 support |
| BroSDK native library | brosdk.dll, brosdk.so, or brosdk.dylib |
On Windows, this project includes dlfcn-win32 to provide dlopen / dlsym style dynamic loading.
At startup, the demo searches for the BroSDK native library in this order:
- Full path from the
BROSDK_RUNTIMEenvironment variable. - Next to the demo executable.
3rdparty/brosdk/next to the demo executable.- System dynamic-library search path.
Recommended placement:
| Platform | File |
|---|---|
| Windows | 3rdparty/brosdk/brosdk.dll |
| Linux | 3rdparty/brosdk/brosdk.so |
| macOS | 3rdparty/brosdk/brosdk.dylib |
If the corresponding file already exists under 3rdparty/brosdk/, the CMake build copies it to the executable output directory after build.
cmake -S . -B build
cmake --build build --config DebugThe executable is usually generated at:
build/Debug/browser-sdk-cpp-demo.exe
cmake -S . -B build
cmake --build buildThe executable is usually generated at:
build/browser-sdk-cpp-demo
Windows:
.\build\Debug\browser-sdk-cpp-demo.exemacOS / Linux:
./build/browser-sdk-cpp-demoInteractive mode is recommended for full debugging because sdk_init, open, wait-open, close, wait-close, and shutdown all run in the same process.
Use inline parameters:
init <userSig> [workDir] [port] [debug]
Example:
init eyJhbGciOi... C:/BroSDK-Demo 9527 true
Use a JSON file:
init-file examples/init.json
Example file:
{
"userSig": "REPLACE_WITH_YOUR_USER_SIG",
"workDir": "C:/BroSDK-Demo",
"port": 9527,
"debug": true
}info
browser-info
Simple command:
open 2041695386304778240 https://example.com
Use a JSON file:
open-file examples/open.json
Wait for the final open result:
wait-open 2041695386304778240 120
sdk_browser_open is asynchronous. The direct return code only indicates whether the task was accepted. The final result should be determined by browser-open-success or browser-open-failed from the asynchronous callback. After browser-open-success, CDP is usually ready for follow-up business logic.
Simple command:
close 2041695386304778240
Use a JSON file:
close-file examples/close.json
Wait for the final close result:
wait-close 2041695386304778240 120
sdk_browser_close is also asynchronous. The final result should be determined by browser-close-success or browser-close-failed callback events.
token-update <newUserSig>
token-update-file examples/token-update.json
shutdown
You can also execute a single command directly:
.\build\Debug\browser-sdk-cpp-demo.exe help
.\build\Debug\browser-sdk-cpp-demo.exe init-file examples/init.jsonJSON file paths are resolved relative to the current working directory. If you run from the repository root, use examples/....
| Command | Description |
|---|---|
help |
Print command help |
init <userSig> [workDir] [port] [debug] |
Call sdk_init with inline parameters |
init-file <json-file> |
Call sdk_init with a JSON request body |
info |
Call sdk_info |
browser-info |
Call sdk_browser_info |
browser-install-file <json-file> |
Call sdk_browser_install |
open <envId> [url1] [url2] ... |
Generate a simple request and call sdk_browser_open |
open-file <json-file> |
Call sdk_browser_open with a full JSON body |
close <envId> [envId] ... |
Generate a simple request and call sdk_browser_close |
close-file <json-file> |
Call sdk_browser_close with a full JSON body |
env-create-file <json-file> |
Call sdk_env_create |
env-update-file <json-file> |
Call sdk_env_update |
env-page-file <json-file> |
Call sdk_env_page |
env-destroy-file <json-file> |
Call sdk_env_destroy |
token-update <userSig> |
Call sdk_token_update |
token-update-file <json-file> |
Call sdk_token_update with a JSON body |
wait-open <envId> [timeoutSeconds] |
Wait for browser-open-success or browser-open-failed |
wait-close <envId> [timeoutSeconds] |
Wait for browser-close-success or browser-close-failed |
events |
Print cached asynchronous event summaries |
clear-events |
Clear cached asynchronous events |
shutdown |
Call sdk_shutdown |
quit / exit / q |
Exit the demo |
The demo registers sdk_register_result_cb() immediately after the runtime is loaded. All asynchronous events are printed to the console and cached in memory for events, wait-open, and wait-close.
Current behavior:
sdk_initsynchronous result is returned directly bysdk_init.sdk_browser_openfinal result comes from the asynchronous callback.sdk_browser_closefinal result comes from the asynchronous callback.sdk_token_updatefinal result comes from the asynchronous callback.
Typical browser-open success event:
{
"code": 0,
"reqId": 369488048,
"type": "browser-open-success",
"msg": "ok",
"data": {
"envId": "2041695386304778240",
"status": 2,
"statusName": "Started",
"progress": 100,
"cdpReady": true
}
}Field interpretation:
progress: 100means the startup flow is complete.type: browser-open-successmeans the environment is ready.cdpReady: truemeans CDP has connected successfully.
env-create-file, env-update-file, env-page-file, and env-destroy-file forward the JSON request body directly to the BroSDK environment APIs.
That means:
- These commands are synchronous.
- The returned body is the raw backend JSON.
- The full field contract follows the BroSDK SDK documentation and server-side environment model.
Minimal page query example:
{
"pageIndex": 1,
"pageSize": 10
}Check:
BROSDK_RUNTIMEpoints to the correct file.- The native library exists next to the executable.
- The native library exists under
3rdparty/brosdk/. - The dynamic library filename matches the current platform.
This is expected.
1meansCL_DONE.- It only means the asynchronous task was accepted.
- The final result still depends on callback events.
Check:
- The
envIdis correct. - The SDK was initialized successfully.
- The console already printed a
*-failedevent. - The browser core is still downloading or starting.
| Repository | Description |
|---|---|
| brosdk | Native BroSDK repository with C/C++ APIs, headers, and platform dynamic libraries |
| brosdk-core | BroSDK browser fingerprint core releases |
| brosdk-docs | SDK documentation, API references, and integration guides |
| browser-demo | Full server-side and desktop client example |
MIT