[Xperia Z1 Compact Android Development] MSe1969:
Hi,

Q1:

Short answer: Actually, we use a fork of the AICP kernel - that's why. :)

Long answer: When you build a device, roughly spoken, you have a huge device-inpedendent portion of your build-tree - in our case the 'vanilla' LineageOS tree (forks needed for the microG-build have all 'lineage-15.1' branches, which are kept 100% in synch with LineageOS and with the microG-build modifications using the 'lin-15.1-microG' branches). And then you have the device-dependent parts, which is always: the kernel, the device configuration and the vendor blobs. AICP Oreo is based on LineageOS, LineageOS does not officially support the Z1c for Oreo, so we took the device-dependent stuff from AICP.

Q2:

Short answer: Signing has no inteference with the kernel - if you would like to play around with a different kernel (which of course must be suitable to work with the device and our ROM), you can do so and the build's signature has no influence on the kernel you use.

Long answer: Technically spoken, a build is always signed, but by default, with publicly known 'test keys'. In fact, each APK is signed and when you would install an update, the package manager in android checks, whether the signature of the APK matches and only allows the update in that case. This is an important security feature to prevent installation of fake apps pretending to be updates of your regular apps. When you build an app, to sign it, the secret private key is needed, whilst the verification happens with the known public key.

The shipped apk files in /system/app and /system/priv-app each are signed, depending on their function, with one of the following keys: releasekey, platform, shared or media

In a build simply signed with the publicly known test-keys (this is the case, if you simply follow the regular AOSP or LineageOS or whatever ROM's build instruictions without caring about signing), it accepts updates to those system apps signed with these keys - as the private test-keys are publicly available, everybody can compile and sign "updates" to those system apps and try to publish them and try to trick you into installing them.

Example 1:

Assume, somebody publishes somewhere an APK called "Super-advanced-Jelly-Browser-update", which is a modified version of LineageOS's Jelly browser and signs with the test-keys. With a test-key (aka: "unsigned") build, you could simply install this apk as "update" to the shipped Jelly browser, with a signed build, the installation would be refused. This may feel uncool, if this app was the great product of an honest developer on XDA, who really did a great job to bring new features in to the app; but it would on the other hand also protect you from installing e.g. a fraudulent scam release recording all the password you enter while using this app in order to secretly submit them to a hacker site.

Example 2:

Whilst you can encrypt the /data partition (and you should do that!!!), the /system partition is read-only unencrypted. Somebody gaining temporarily physical access to your device could flash a specifically crafted apk with auto-start and background permissions singed with the 'platform'-testkey into /system/priv-app (remember: apps signed with the 'platform' key in /system/priv-app are officially entitled to request and use system privileges in android - this is a regular feature, also in Stock ROMs). Now use your phantasy . . . - if the ROM however has got different platform and release keys, this app would be treated like 'signed with an own key', which means, that it can't make use of

any

system-privileges (I actually haven't tried that, it may even be, that it would be entirely blocked from launching due to wrong keys - and yes, somebody gaining physical access to your device to flash stuff is still bad enough . . . !)

That's the background, and that is also, why you can't 'dirty-flash' a build signed with other keys over an existing build either.