Develop Reference

How can I access vehicle properties which have signature permission? Is it possible to root Android automotive OS?

I need to access VHAL properties like ABS_ACTIVE, ENGINE_RPM, etc which are restricted with signature permissions. The third-party app access to VHAL is restricted with permissions. I will get OEM signature permission in the production build, but for testing, I need to sign my app with an AOSP certificate or I have to move my app into the system folder.
Where can I find those certificates?
How can I sign my app with those certificates?

Build your own custom system image https://source.android.com/devices/automotive/start/avd
Include your apk in the system image as part of the build (& you will need to pre-grant access to your apk (https://source.android.com/devices/tech/config/perms-allowlist)
The system images that are published by Google/Volvo/Polestar are user/release-keys and hence you won't be to get those platform keys for it.

For testing you can sign your app with the default platform key that comes with android.
The Android tree includes test-keys

Android APK signed with PLATFORM key not given system privileges?

I have access to an Android tablets' platform key and certificate. I'm attempting to build an app and install it with system level privileges by doing the following:
Create a Java KeyStore file with platform.pk8 and platform.x509.pem using the bash script called platform_import_keystore found on GitHub.
In AndroidManifex.xml add the following:
<uses-permission android:name="android.permission.READ_LOGS"/>
android:sharedUserId="android.uid.system"
Sign APK with PLATFORM key and certificate using a Java KeyStore file in Android Studio.
Install APK
When the app runs, the system denies READ_LOGS permission.
Why isn't my app running with system level permissions?

What #Mark mentions is correct to some extent, for system apps.
I think you are doing something else wrong.
I have tried this with system apps as well, and as long it was signed with the platform keystore, it works. Now this was on Android 8 and Android 9. You haven't mentioned the AOSP version running the device.
That changes things AFAIK, so if it's AOSP 10+, it might behave differently.
Also the other comments are missing another key thing SELinux. SELinux is not permissive for user builds. Verity is enabled, and you cannot have root access. So you cannot push the app into /system/priv-app/ or push it into /vendor/app/.
You cannot access system resources without proper SE Policy files. You can check the logs yourself, to see avc denied messages.
I think overall what you are seeing should be inline with AOSP's security ideals. An app signed with System keys should not be able to get system permissions. It also needs to be located in the correct place, either as a privileged app or vendor app. Such apps need to be whitelisted. There's a built in script in AOSP source to even generate the permissions for whitelisting (it produces the required xml)
There's two classes of system apps, /system/app/ and /system/priv-app/
The privileged apps are the only ones that get signature level permissions, and according to newer versions of android, you need to enable whitelisting in the /system/etc/priv_app-permissions_device_name.
If you make any changes to the system or vendor when verity is enabled, firstly they are mounted read only, but somehow if you do make a change, the device will brick itself. This is the security feature. All custom development needs to be done in userdebug builds with SELinux in permissive mode, and then all the permissions need to be predefined, SE Policies fine tuned to utmost minimal, only then the user build can function normally. User build is not at all suitable for AOSP development activities, even if it's just for testing or trying out a single app.
User build is production type build that the end user can use and is not for development. It's the most secure form of android, so if you have platform keys, it may never be enough.
All that being said, I'm sure you don't have the right keys. Just pull an app from system/priv-app/ and use keytool or similar to check it's signature, and then try to match with your release apk.
It's little complicated as it is, and kind of hard to explain and there are levels of permissions also in android, so if you aren't following a specific approach/path, you will not be able to get it to work.

Signing my android application as system app

In my company, we would want total control for battery consumption in the field, using only 2g and gps could drain the battery awfully fast. What we decided is that we need to have root access to the mobile phone, So that when phone is idle, we would turn off those needless battery consumption.
And also we would not allow users to uninstall it and clear data to it.
My Question is :
Where do I get these signature key?
Is it going to like a root access If ever I successfully managed to
sign it?
What is the difference between Root vs Signed with key?

Answering your three questions:
1 - Where do I get these signature key?
From Android's own documentation in the section Release Keys
The Android tree includes test-keys under
build/target/product/security
But the next part is where you should really pay attention
Since the test-keys are publicly known, anybody can sign their own
.apk files with the same keys, which may allow them to replace or
hijack system apps built into your OS image. For this reason it is
critical to sign any publicly released or deployed Android OS image
with a special set of release-keys that only you have access to.
So basically unless you can somehow gain access to manufacturer's pvt keys it might be difficult to achieve this. This is why a user in a previous comment was saying this is usually achieved by producing your own build.
2 - Is it going to like a root access If ever I successfully managed
to sign it?
You will not get "root access" by doing it, but you will get access to an extremely high level of access. Specifically, what this achieves you is that you will be granted permissions with declared android:protectionLevel="signature" which is, arguably, the most exclusive one.
One other dangerous consequence (or fun, depending on how you look at it) of this is that you can now run your app under system user process android:sharedUserId="android.uid.system" - under android's "process sandboxed" security rules this would normally fail.
3 - What is the difference between Root vs Signed with key?
With an app signed with the platform key from your build, you can get the permissions mentioned above, or run your app with UID 1000 (system uid) which in android is much more powerful than the UIDs of other apps because of the permissions it can request, this is a behaviour specific of Android though.
In a rooted device, you can use UID 0 (root) which has the broadest access in linux based systems, you can bypass most of the security sandboxing/checks/fences on the OS.
Hope this helps ;)

Well below is your answer,
You can find platform keys from
HERE. The command to sign apk (for linux) is:
java -jar signapk.jar -w platform.x509.pem platform.pk8 APPLICATION.apk APPLICATION_sign.apk
onward Android 10 lib64 library path need to provided which can be found at android/out/host/linux-x86 after generating a successful build, one can copy folder or simply provide its path to generate sign APK
java -Djava.library.path="<path to lib64>" -jar signapk.jar -w platform.x509.pem platform.pk8
If you sign your apk with platform keys you won't required root access you can simply install it from "adb install" command, and yes in someway it is like root 'cos it can access all internal api but keep in mind if your app is system signed then you can't write external storage.
First of all don't combine both root is user where system app is application type which distinguish from normal application below link might clear your confusion regarding it.
what-is-the-difference-between-android-user-app-with-root-access-and-a-system-ap

For anyone coming to this question and even after reading the comments not being able to make it work, it might be because there're some things missing (specially if getting OPENSSL errors), here's everything you need.
Sign APK with test keys from the AOSP
git clone https://android.googlesource.com/platform/prebuilts/sdk.git - Careful it's ~6GB, or you can download what you need, the signapk.jar file and the libraries.
download the platform.x509.pem and platform.pk8 from https://github.com/aosp-mirror/platform_build/tree/master/target/product/security (or get your own keys corresponding to the image)
With java installed, change the following command with the right paths for the files, the lib64 in the sdk you just cloned, the signapk.jar file, the platform key files and the apk to sign
java -Xmx2048m -Djava.library.path="~/../sdk/tools/linux/lib64" \ # In the cloned sdk
-jar ~/../sdk/tools/lib/signapk.jar \ # In the cloned sdk
platform.x509.pem platform.pk8 \ # The keys for signing (from step 2)
app-prod-release.apk release.apk # The app to sign and the signed app

Update of Android system app, with/without platform signature

I have a system app that the OEM installs with the system image, but is signed by me. If I upload an updated apk to the market, will the market app silently install this update automatically?
If my system app is instead signed with the platform signature instead of mine, this means any updates also have to be signed with the platform signature, correct? Can a platform-signed apk be updated from the market?

Lets first of all clarify the difference between all types of apps.
System apps are those that are located in the /system/app folder. These applications have a flag ApplicationInfo.FLAG_SYSTEM set. In an ordinary device the partition /system is mounted for read-only access. Thus, a system application cannot be updated because it is located in the read-only location. These applications can be updated only as a part of OTA update.
Ordinary apps are located on the /data partition which is read-write. Thus, these applications can be updated by a system.
Now lets talk about signatures. Some Android components are protected with permissions of signature type. This means that if you want to have access to a component protected with this type of permission, your application must be signed with the same certificate as a protected component. This is true not only for Android system, but also for Android applications, i.e. in your application you can have a component that is protected with a signature permission, thus, only applications that have the same signature will have access to this component.
The third thesis which we require to answer your question is that Android prohibits the installation of the packages that have the same package name but different signatures.
Thus,
I have a system app that the OEM installs with the system image, but
is signed by me. If I upload an updated apk to the market, will the
market app silently install this update automatically?
If my system app is instead signed with the platform signature instead
of mine, this means any updates also have to be signed with the
platform signature, correct? Can a platform-signed apk be updated from
the market?
The answer is no. Although the apps that are located in /system/app can be signed with a certificate that differs from the platform one, the update of these applications is possible only with system update.
To solve your problem you can change the packagename of your application, sign it with your (if the application does not require to have access to protected Android components) or platform (if the application should have access to protected components and if you have access to this signature) and put this application into market. Then, you'll receive the updates of your application through the market.

The system will not treat an apk in /data/app as an update unless the signatur matches the one in /system/ap

grant system permissions to an app in the android emulator

I am building an app that will be bundled on an android device as a system app. The manufacturer is a ways out on delivering the device to us, so in the meantime I'd like to grant my app system level permissions in the emulator so I can work on an auto update feature that will do silent installs of APKs without any interactions from the user. From what I've read, its my understanding that the only way to be able to do silent installs on android is if your app is signed with the same cert as the OS. So how can I simulate this in the emulator?

If you want a signatureOrSystem permission, you just need to be placed on the system image; you don't need to be signed with any special cert. You can do this as a one-off (until you exit the emulator) like this:
> adb root
> adb remount
> adb push /path/to/My.apk /system/app/My.apk
Once you have done that, you can use the normal process to install further updates on the data partition ("adb install -r /path/to/My.apk" which is what the developer tools do when you run from Eclipse). When installing this way, the app retains any signatureOrSystem permissions it had requested from the original version on the system image, but can not gain any new such permissions.
If you need pure signature permissions, you need to sign your app with the same cert as whatever is declaring those permissions (typically the core framework, but the media system is a separate cert etc). If you are requesting signature permissions you don't need to be installed on the system image, you can just install it as a normal app and it can still get the permissions because of the signing.

As far as I can tell, you need to:
download the Android source and build an emulator firmware image.
sign your application with the keys in the Android source tree at /build/target/product/security/.
add android:sharedUserId="android.uid.system" to your application's manifest.
run your application on an emulator using the image built in step 1.
The reason for having to build your own firmware image is so that you can get at the keys. Now, it might be possible that the keys for the standard emulator image are available somewhere, which will save you the long and exceedingly tedious process of building your own Android, but I'm afraid I have no idea where these might be.
Disclaimer: never tried this myself.