* Installing the Android server on certain devices will not grant
'force-queryable' permissions, necessary for capture layer
discovery for API>=30. Reinstalling a second time fixes this
issue. With this change, the 'force-queryable' attribute is
checked post-install. If the check fails, it prompts a second
installtion attempt.
* Solution tested on:
- OPPO find X6, Android 13 (affected device)
- Google Pixel 6 and 7, Android 13
- SM-G930F, Android 8
* When we detect a new version of Android and a 64-bit device where the 32-bit
version of RenderDoc fails to install completely, ignore this and don't warn
the user about it.
* Synchronous commands are on the stack, so incrementing the done flag should be
the last thing we do to interact with them. That includes checking for self-
deletion afterwards
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
We need to check the android version running on the device to know
whether or not we need to make the adb install command use the
--force-queryable flag
Devices running Android R/11/SDK 30 are ones which support this flag
Added the --force-queryable flag to the adb install command for
renderdoc Android on devices running Android R/11/SDK 30
A feature being introduced in Android R requires all explicit
interactions between
apps to be declared ahead of time (either via manifest or during adb
install)
The --force-queryable flag during adb install does this, and is what
allows for the
shared objects from renderdoc (in this case the layers) to be
discoverable by
other apps targeting SDK 30+
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
Updated permissions for the renderdoccmd app based on which version of
android the app is running on
**WRITE_EXTERNAL_STORAGE for <R
**MANAGE_EXTERNAL_STORAGE for >=R
Updated the Java portion of renderdoccmd to check/request the correct
permission based on android version
Changed the file path for renderdoc files on Android based on the
version of Android the connected device is running
**/sdcard/Android/data/$PACKAGE_NAME for <R
**/sdcard/Android/media/$PACKAGE_NAME for >=R
* This allows persistent config storage and registering tweak variables that
works independent of the UI's configuration.
* Config vars can be debug only, which means they will be compiled out in stable
version releases. This allows for debug-logging tweaks that are available in
all builds (including nightly builds) for diagnostic purposes, but have zero
overhead in stable releases.
* Variables have a loose hierarchy defined with _ or . to separate nodes.
* We instead always have 3rdparty/ in the relevant include search paths and rely
on that. Each library still has its own unique base dir within 3rdparty to
clarify where the include is coming from.
