module: move daemon start exclusively to service.sh

[CaptainThrowback]

Starting daemon during post-fs-data can cause Play Integrity detection for devices that do not need to use a Play Integrity Fix module.

[JingMatrix]

Thanks for your contribution. Could you please tell me how to verify your claim? That is say, what would shows that LSPosed causes Play Integrity detection and your commit indeed fix it?

[pershoot]

@JingMatrix I can test to see if, on my end, this does allow for passing Play Integrity (at least DEVICE) without spoofing, while using TrickyStore. Currently, LSPosed use requires me to spoof, when used with TrickyStore (>= 1.3). Without it, I do not seem to need spoofing. Of note, TS <1.3 requires disablement of Zygisk to not need spoofing, for me. This can be validated with a Play Integrity check via Developer Settings (Play Store).

[CaptainThrowback]

Thanks for your contribution. Could you please tell me how to verify your claim? That is say, what would shows that LSPosed causes Play Integrity detection and your commit indeed fix it?

Requirements:

• Device rooted with KernelSU (LKM) or APatch
• TrickyStore w/unrevoked keybox for Strong Integrity
• Module that sets sensitive props
  • Shamiko*
  • Zygisk Assistant*
  • Play Integrity Fork (by @osm0sis) in "scripts-only" mode
  • Sensitive_props

*Requires 3rd party Zygisk solution (Zygisk Next, ReZygisk, Zygisk-FOSS)

First, you need to confirm that the device can pass Strong Integrity with only the above setup (i.e. without PIF). If so, then you can proceed. If not, then the device isn't a good test candidate.

Steps to reproduce:

1. Once Strong Integrity is confirmed, install a Zygisk solution and unmodified LSPosed zip.

2. Check Play Integrity (should show Basic only - if it still shows Strong, then device is not a good test candidate)

3. Modify scripts as in pull request and reboot

4. Check Play Integrity (should now show Strong)

This process has been confirmed by multiple people on XDA. I first reported it here:

https://xdaforums.com/t/tricky-store-bootloader-keybox-spoofing.4683446/post-89673058

Here are some of the follow-up posts of people using this method successfully:

• https://xdaforums.com/t/dev-apatch-an-alternative-root-solution-to-kernelsu-and-magisk.4655727/post-89677764
• https://xdaforums.com/t/dev-apatch-an-alternative-root-solution-to-kernelsu-and-magisk.4655727/post-89679189
• https://xdaforums.com/t/dev-apatch-an-alternative-root-solution-to-kernelsu-and-magisk.4655727/post-89700377

There may be more but that's what I found so far.

If you have any additional questions, let me know.

--Cap

[Stillhard]

Requirements:

• Device rooted with KernelSU (LKM) or APatch

This is not sound good, what's the side effect for Magisk' users?

[JingMatrix]

If I understand correctly, with PIF by chitroman enabled, the strong verdict can always pass without any problem? Am I correct?

[CaptainThrowback]

Requirements:

• Device rooted with KernelSU (LKM) or APatch

This is not sound good, what's the side effect for Magisk' users?

There should be no "side effect" for Magisk users. This change specifically allows some devices that DON'T use Magisk to pass Strong Integrity without any type of Play Integrity "Fix".

It should be simple enough for you to confirm that LSPosed will continue to function without an issue with these changes while rooted with Magisk.

[CaptainThrowback]

If I understand correctly, with PIF by chitroman enabled, the strong verdict can always pass without any problem? Am I correct?

Correct, if a valid fingerprint is used with PIF, then Strong should pass regardless of this change.

However, the point of the change is to allow devices that DON'T need to use PIF with a non-Magisk root solution to pass Strong Integrity. All other devices should remain unaffected.

[JingMatrix]

Any specific reason that you want to get rid of PIF? I think it does a good job.

[CaptainThrowback]

Any specific reason that you want to get rid of PIF? I think it does a good job.

If it isn't necessary with this minor change, then why should people have to use it? Besides the fact that PIF requires a working/unblocked fingerprint for Play Integrity to pass, and those are finite, and frequently need to be changed.

So why would I use a solution that's variable if there's a way to avoid it? If the device fingerprint can be used, that means there is no need to spoof fingerprints or hunt to find one that hasn't been blocked. There are no issues with RCS not working due to a blocked fingerprint. And the fingerprint doesn't need to be changed every 6 weeks (or sooner) because it's a Beta print.

Overall, not needing PIF is a game-changer, in the long run.