심각한 정렬 충돌이 발생합니다. 내 앱은 기본적으로 화면이 잠자기 상태가 될 때 활동을 시작하는 원격 서비스입니다. 이것은 어떻게 방송 수신기를 끄는지를 통해 매우 간단하며 새로운 작업으로 활동을 시작하려는 명백한 의도입니다. 활동은 기본적으로 핵심 이벤트에 응답하고 간단한 텍스트를 표시하는 역할을 담당합니다.특정 응용 프로그램이 실행 중일 때 StartActivity 인 텐트가 실패합니다.
2.0에서 추가 된 몇 가지 창 플래그 덕분에 활동에서이를 수행 할 수 있습니다. 그들은 lockscreen의 위에 그들을 두거나, lockscreen을 완전히 닫는 방법으로 만들어 질 수 있습니다. 이 방법은 기본적으로 사용자가 잠금 화면을 해제하지 않고 초점을 맞 춥니 다. 2.0의 알람 시계는 플래그를 사용하여 장치를 깨우고 알람 대화 상자를 표시합니다. 나는 화면이 잠자기 상태 일 때 사용자가 자신의 웨이크 업 잠금 화면을 볼 수 있도록 내 활동을 배치하기 위해 그것들을 사용한다. 스크린 오프시에 만드는 이유는 잠자기 화면을 처음 보았을 때 사용자가 깨어날 때 지체되는 것을 없애고 활동을 보는 것입니다. 또한 잠자기 상태에서 즉시 작업을 수행하면 키 이벤트를 효과적으로 처리 할 수 있도록 포커스를 가질 수 있습니다.
일부 앱을 제외하고 프로세스가 완벽하게 작동합니다. 지금까지는 브라우저 (그리고 심지어 돌고래 브라우저)와 페이스 북 앱이 실행되는 동안 버그가 일관된 것 같습니다. 이 버그는 GTalk 나 Launcher에서 결코 발생하지 않습니다. 드물기는하지만 메시징 앱에 복제 될 수 있습니다. 이 앱이 활성화되어있는 동안 내 활동이 잠자기에 만들어지지 않는 이유를 알 수 없습니다. 내 원격 서비스는 여전히 화면을 브로드 캐스트 해제하고 명시된 의도에 대해 startActivity를 수행합니다. 그 모든 정보가 로그에 저장됩니다. 내 onCreate가 호출되지 않습니다. 대신 우리는 화면을 다시 깨울 때 호출됩니다.
원격 서비스가 생성 될 때 부분 웨이크 록을 유지하기 위해 컨트롤로 시도했지만 문제가 지속됩니다. 그래서 나는 그것이 CPU가 잠을 자는데 문제가되었다고 생각하지 않는다. 이러한 특정 앱에서만 문제가 복제되기 때문에 왜 활동 시작이 실패하는지 상상할 수 없습니다. 이러한 앱이 다른 앱의 제작 능력을 방해하기 위해 무엇을 할 수 있습니까? 실행 모드로 singleInstance를 사용하여 사용자 프로세스가 해당 활동을 절대로 호출 할 수 없도록 할 수 있습니다. 사용자가 잠금을 해제하고 생성 될 수있는 한이 작업이 정상적으로 작동 할 때 멀리 떨어지길 원합니다. singleInstance는 동일한 잠금 화면에서 원격 서비스가 모니터링하는 사용자 작업을 기반으로 특정 작업을 처리 할 수 있도록합니다.
내 프로젝트 페이지에서 내 소스 코드를 볼 수 있습니다. http://code.google.com/p/mylockforandroid/source/browse/#svn/trunk/myLock/src/i4nc4mp/myLock
내 CustomLockService 및 NoLockService 변형에 모두 문제가 발생합니다. 이 두 서비스는 Lockscreen 또는 ShowWhenLockedActivity를 시작하고 버그가 목격됩니다. 버그의 최종 결과를 보여주는 빌드 - 버그로 인해 사용자가 3 번 잠금 해제를 시도해야합니다. 이는 oncreate가 마침내 성공할 때 깨어나서 사용자가 정상적으로 키 이벤트 로직 덕분에 자동으로 해고 될 것이므로 활동을보고 있기 때문입니다. 연기 된 onCreate로 인해 발생하는 것처럼 보이지 않으므로 다시 보내야합니다. 활동이 제대로 시작되고 화면이 잠자기 상태가되었으므로 다음 절전 모드에서 예상되는 기능이 다운로드 탭에서 다운로드 할 수 있습니다.
이것은 특정 앱에서만 발생하는 매우 불합리한 것 같습니다. 나는 나의 활동 정의에서 몇 가지 중요한 실수를 범하지 않는 한 해결책에 대한 아이디어와 생각이 아주 당황 스럽다.
을 내가 수동으로 시작하려고하는 작업 대기를함으로써 문제를 해결 활동. 갈등이 무엇이든 그것은 타이밍의 결과입니다. 아마도 뿌리 깊은 OS 프로세스 문제 일 것입니다. 딜레이는 완벽한 잠금 장치입니다. 왜냐하면 타임 아웃 수면이 시작될 때 키가 보호 받기 위해 5 초 유예 기간을 존중하도록 내 잠금 재 지정을 원하기 때문입니다. 근본 원인에 대한 답이 없습니다. 내가 그랬 으면 좋겠어. – mylock
또한, 화면에서 부분적으로 wakelock을 가져 오는 것은 내 activity onStart가 화면에서 호출 될 때까지 기다렸다가 그 문제를 해결했습니다. 나는 그것이 다른 프로세스에 의해 지연되고 CPU의 sleep 전에 끝날 수 없다고 생각한다. 그래서 태스크의 쓰레드가 돌아 다니고 있지만 wakelock은 코드를 더 효율적으로 만든다. – mylock