This exception is a super-type of:
- ClassNotFoundException
- IllegalAccessException
- InstantiationException
- InvocationTargetException
- NoSuchFieldException
- NoSuchMethodException
Use it to simplify.
Create the service managers from each manager wrapper class rather than
from their getter in ServiceManager.
The way a wrapper retrieve the underlying service is an implementation
detail, and it must be consistent with the way it accesses it, so it is
better to write the creation in the wrapper.
Reported by checkstyle:
> [ant:checkstyle] [INFO]
> scrcpy/server/src/main/java/com/genymobile/scrcpy/wrappers/ClipboardManager.java:48:
> Line is longer than 150 characters (found 167). [LineLength]
On Android 11, it is possible to start the capture only when the running
app is in foreground. But scrcpy is not an app, it's a Java application
started from shell.
As a workaround, start an existing Android shell existing activity just
to start the capture, then close it immediately.
PR #3757 <https://github.com/Genymobile/scrcpy/pull/3757>
Co-authored-by: Romain Vimont <rom@rom1v.com>
Signed-off-by: Romain Vimont <rom@rom1v.com>
Remove USER_ID from ServiceManager, and replace it by a constant in
FakeContext.
This is the same as android.os.Process.ROOT_UID, but this constant has
been introduced in API 29.
PR #3757 <https://github.com/Genymobile/scrcpy/pull/3757>
On mouse click events:
- the first button pressed must first generate ACTION_DOWN;
- all button pressed (including the first one) must generate
ACTION_BUTTON_PRESS;
- all button released (including the last one) must generate
ACTION_BUTTON_RELEASE;
- the last button released must in addition generate ACTION_UP.
Otherwise, Chrome does not work properly.
Fixes#3635 <https://github.com/Genymobile/scrcpy/issues/3635>
Signed-off-by: Romain Vimont <rom@rom1v.com>
There were exactly one instance of ServiceManager and Settings, stored
in Device.
Since a Device instance is not created by the CleanUp executable, it was
not straightforward to call wrapper methods on cleanup.
Remove this artificial restriction and expose them publicly via static
methods (this is equivalent to expose a singleton, but less verbose).
The previous commit replaced the IInterface instance (the "input"
service) by the InputManager instance (retrieved by
InputManager.getInstance()).
Both define an "injectInputEvent" method, but the alternate version
(probably) does not concern the InputManager.
This reverts commit b7a06278fe.
PR #3190 <https://github.com/Genymobile/scrcpy/pull/3190>
Settings read/write errors were silently ignored. Report them via a
SettingsException so that the caller can handle them.
This allows to log a proper error message, and will also allow to
fallback to a different settings method in case of failure.
PR #2802 <https://github.com/Genymobile/scrcpy/pull/2802>
Until now, the code that needed to read/write the Android settings had
to explicitly open and close a ContentProvider.
Wrap these details into a Settings class.
This paves the way to provide an alternative implementation of settings
read/write for Android >= 12.
PR #2802 <https://github.com/Genymobile/scrcpy/pull/2802>
This commit in AOSP framework_base added a parameter "attributionTag" to
the call() method:
12ac3f406f%5E%21/#F17
As a consequence, the method did not exist, so scrcpy used the legacy
call() method (using the authority "unknown") as a fallback, which fails
for security reasons.
Fixes#1468 <https://github.com/Genymobile/scrcpy/issues/1468>
Expose methods to access the Android settings using private APIs.
This allows to read and write settings values immediately without
starting a new process to call "settings".