최근 꽤 많은 vivo/iQOO 사용자들이 ADB에 의존하는 많은 모듈들이스크립트、최적화도구갑자기 "작동하지 않는다"고 말합니다.

표면적으로는 모듈이 고장 났거나 명령 실행이 실패한 것처럼 보입니다. 하지만 현실은 좀 더 복잡합니다: 많은 명령이 성공적으로 실행되는 것처럼 보이지만, 실제로는 시스템이 더 이상 이러한 수정을 받아들이지 않습니다.

여기서는 현재 직면한 몇 가지 주요 쟁점에 대해 간략히 논의하겠습니다.
설정 설정 시 문법이 사실상 무효가 되었습니다
이전에는 많은 ADB 모듈이 시스템 설정 테이블을 수정하기 위해 다음과 같은 명령어를 사용했습니다:
settings put system xxx xxx
settings put secure xxx xxx
settings put global xxx xxx
이 방법은 과거에는 매우 유용했습니다—빠른 실행, 간단한 호환성, 그리고 많은 SetEdit 항목을 이렇게 작성할 수 있습니다.

하지만 이제 vivo 시스템에는 명백한 한계가 있습니다:
settings put …
명령줄은 오류가 없어 보일 수 있고 심지어 "실행 성공"이라는 인상을 줄 수 있습니다.
하지만 문제는 시스템이 이 쓰기를 단순히 무시할 수도 있다는 점입니다.

즉, 전통적인 실패가 아니며, 오류를 반환하거나 권한 부족을 나타내지 않을 수 있으며, 표면적으로 실행되고 실제 값이 시스템에 채택되지 않는 경우입니다.

이것이 바로 많은 모듈이 등장하는 이유이기도 합니다:

대본이 완성됐어
이 소프트웨어는 성공을 이끌었습니다
ADB는 명백한 오류를 보고하지 않았습니다
하지만 기능은 전혀 변하지 않았습니다

근본적인 이유는 설정이 더 이상 신뢰할 수 없기 때문입니다.
setprop는 일반 ADB 권한으로 가볍게 사용할 수 있는 것이 아닙니다

또한 다음과 같은 시험을 통과하려는 유형의 모듈도 있습니다:

setprop xxx xxx

시스템 속성을 수정하기 위해서입니다.
하지만 이 솔루션의 문제점도 명확합니다: 많은 프로펠러가 시스템 수준의 권한이 필요합니다

일반적인 ADB 셸 권한은 동일하지 않습니다 root, 그리고 이는 시스템 특권과 같지 않습니다.
따라서 시스템 동작, 디버그 스위치, 벤더 속성과 관련된 일부 세트프로프는 일반 ADB에서 실제로 수정할 권한이 없습니다.

어떤 속성은 일시적으로 작성할 수 있고, 어떤 것은 직접 거부되며, 어떤 속성은 대상 논리에 영향을 주지 않고 작성됩니다. 특히 벤더 시스템이 점점 엄격해지면서, 일반 ADB에 의존해 시스템 속성을 변경하는 것은 기본적으로 안정적인 해결책이 아닙니다.

간단히 말해:
adb 셸은 셸 사용자 권한만 얻고, 보편적 권한은 얻지 않습니다. setprop이 작동하는지는 특정 속성, SELinux 정책, 시스템 권한, 벤더 제한에 따라 다릅니다.
설정을 우회하려면 콘텐츠 제공자로 가면 됩니다

만약 만료된 'settings put'에 의존하지 않고 SetEdit 관련 테이블을 수정하는 것이 목표라면, 현재 가장 실현 가능한 방법은 Content Provider 문법을 사용하는 것입니다.

대략 이런 식의 사고방식입니다:
content insert
content update
content query

즉, 캡슐화를 위한 설정 설정 레이어를 사용하지 않고, 시스템의 노출된 제공자 인터페이스를 통해 해당 데이터를 직접 조작할 수 있습니다.

이 방법은 '설정 설정'보다 더 근본적이며, 일부 상황에서는 '설정 설정' 문제를 우회할 수 있습니다.

하지만 명확한 단점도 있습니다: 느림

특히 여러 SetEdit 항목을 묶음으로 작성할 때, 각 항목이 하나씩 실행될 경우:
content update
content update
content update

속도가 매우 느려지고 사용자 경험도 눈에 띄게 저하될 것입니다.

소프트웨어 개발자는 여러 셸 스레드를 사용하면 속도를 높일 수 있습니다
수동 운전하는 일반 사용자라면 조금 느려도 그냥 참아야 합니다.
하지만 도구 유형 소프트웨어, ADB 모듈 관리자, 자동화라면,구성그리고 개발자들은 한 스레드에서 다량의 '콘텐츠' 명령을 하나씩 실행하는 것을 중단할 것을 권장합니다.
여러 셸 스레드를 사용해 동시에 실행하는 것을 고려할 수 있습니다. 예를 들어:
여러 개의 'adb shell' 세션은 서로 다른 구성 항목을 병렬로 처리하며, 그룹화하고 스레드별로 작성하여 각 명령어별로 별도로 셸을 시작하는 오버헤드를 줄이고, 명령이 성공적으로 반환되었는지 확인하는 대신 실행 결과를 검증합니다
이렇게 하면 배치 쓰기 속도를 크게 향상시킬 수 있습니다.
하지만 동시 스레드도 그에 맞게 관리해야 합니다; 수십 개 또는 수백 개의 스레드를 무작정 실행하는 것은 권장되지 않습니다.
스레드가 너무 많으면 오히려 시스템에 해가 될 수 있습니다지연명령 차단, 심지어 비정상적인 제공자 반응까지.

더 합리적인 방법은 예를 들어 4개에서 8개의 셸 스레드를 생성하고 장치 성능에 따라 동적으로 조정하는 스레드 풀을 구축하는 것입니다.

이제 '성공'을 판단하는 것은 명령어 반환 값만으로는 안 됩니다
이것이 현재 가장 흔한 함정입니다.
이전에는 많은 모듈에서 성공을 확인하는 간단한 방법이 있었습니다: sh
settings put xxx
명령이 맞으면 성공한 것으로 간주됩니다.
하지만 이제는 그런 판단만으로는 충분하지 않습니다.
더 안전한 접근법은 다음과 같습니다:

1. 목표 값을 작성한다
2. 현재 값을 다시 읽습니다
3. 변경 사항이 진짜인지 비교한다
4. 필요 시 쓰기 메서드를 다시 시도하거나 전환합니다
예를 들어:
settings get global xxx
content query …

값을 되돌려 읽는 것이 진정으로 기대에 부합할 때만 수정이 성공으로 간주됩니다. 그렇지 않으면 소프트웨어가 "활성화됨"을 표시하지만 실제로는 시스템이 전혀 켜져 있지 않을 수 있습니다.
현재 vivo/iQOO의 많은 ADB 모듈이 실패하고 있는데, 이는 꼭 저자 코드 오류 때문이 아니라 시스템 내 관련 인터페이스에 대한 제한이 강화되었기 때문입니다.
이제 대략 다음과 같이 요약할 수 있습니다:
'settings put': 성공한 것처럼 보이지만 실제로는 시스템에 의해 무시될 수 있습니다
'세트프로프': 많은 프로젝트가 시스템/루트 권한을 필요로 하며, 일반 ADB로는 이를 처리할 수 없습니다
'콘텐츠 제공자': 현재 비교적 실현 가능하지만 실행 속도는 느립니다
배치 쓰기: 소프트웨어 개발자는 속도를 높이기 위해 여러 셸 스레드를 사용하는 것이 권장됩니다
성공 확인: 검증 결과를 다시 읽어야 하며, 명령어에 오류가 있는지 단순히 확인할 수는 없습니다
따라서 앞으로 Vivo에 이러한 도구들을 계속 적용하고 싶다면, 핵심 접근법은 '직접 설정 설정'에서 '제공자 작성 + 결과 검증 + 동시성 최적화'로 전환되어야 합니다.
이는 개별 모듈의 문제가 아니라, 시스템 정책이 변경된 후 기존 솔루션이 전반적으로 불안정해진다는 점입니다.

개발자라서 너무 많은 콘텐츠 문법을 쓰고 싶지 않다면 kbattery를 사용할 수 있습니다. 새 버전에서는 kbattery가 설정을 변환하고 문법을 입력할 수 있습니다
다음은 몇 가지 추천 사항입니다:
9 삭제 92⛰️9 삭제 2 삭제 26⛰️45
관련 개발자들이 신속하게 구현을 조정할 수 있기를 바라며, 일반 사용자들이 모듈이 실패하는 것을 보고 저자가 포기한다고 바로 생각하지 않길 바랍니다. 종종 명령이 실행되지 않는 것이 아니라, 시스템이 더 이상 이 방식을 인식하지 못하는 경우가 많습니다.