Apparently there is a way. There are publicly available app signing keys that can be used for testing/developing apps to be installed as system apps. Check this: https://stackoverflow.com/questions/37586255/signing-my-android-application-as-system-app
If I understand it correctly, then signing the apk with one of those keys, instead of a self-signed key, should do the trick.
There are downsides (explained on stackoverflow), but they are hardly applicable in our case.
In Windows adb the same keys
But his were better, because they're from Linux.
Stop trolling again.
I wrote instructions. I wrote clearly Linux manual. Im not using Windows and I cant check if everything is the same on Windows version. So You think Im worse because I dont have Windows or what?
Again, please stop trolling.
Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.
Damn, at first glance I was even glad that such an opportunity existed However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.
It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.
Verifies
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=hexiaohua@rigol.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: f48e7189aac174df7fd19acf58b6d15832760fcf25ac0a6d4bcd5fc1974d4c03
Signer #1 certificate SHA-1 digest: df345a93532e902ff6291668c20ad69da3b72ff6
Signer #1 certificate MD5 digest: 40490c2e0b280e29ba5e46205272e3dc
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: ca871f06fa7ffaa5beda2179a2278a0474d98e6b5e11d9aab2dfb590d8e57292
Signer #1 public key SHA-1 digest: 90ff0ddf5a0881ea080558b3b585dd0352342d8e
Signer #1 public key MD5 digest: 78d923a60c0963a38de1ee05b4556031
-----BEGIN CERTIFICATE-----
MIIECzCCAvOgAwIBAgIUINzTdl44KGbN5zrMwq1QEIADPRMwDQYJKoZIhvcNAQEF
BQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQH
DA1Nb3VudGFpbiBWaWV3MRAwDgYDVQQKDAdBbmRyb2lkMRAwDgYDVQQLDAdBbmRy
b2lkMRAwDgYDVQQDDAdBbmRyb2lkMSIwIAYJKoZIhvcNAQkBFhNoZXhpYW9odWFA
cmlnb2wuY29tMB4XDTIwMDcxMDAzNDg1OVoXDTQ3MTEyNjAzNDg1OVowgZQxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFp
biBWaWV3MRAwDgYDVQQKDAdBbmRyb2lkMRAwDgYDVQQLDAdBbmRyb2lkMRAwDgYD
VQQDDAdBbmRyb2lkMSIwIAYJKoZIhvcNAQkBFhNoZXhpYW9odWFAcmlnb2wuY29t
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtmIPvmnFTAd95RNbqCLS
iOKrilEABcW8rtBCu70ofoOpOWLX5R2NBPWtYtOq+y4EF/dJddUVxOeOdTBngW8J
GfQiU7rqxxzWrskXh437KZYmcnAJxrEQkM7lBifPIYhihlmGCRVMM1eBZRdaRHjA
bSsM7flBMPhM8tpEX3g7kIoKa0NFrb+Z4206WrWX+0tIsvo8yA92pyqcwh4p2Ayx
cUnNWRnQdRU5iunuQmR5IS1uvryVyxYVX4T+WK5bQsupeXuwnTuCHSkJP2WMc5lE
6FZ7B1RcS7Lk+KQQ67S7TaqKp/iMgKM1l99Q74KaYoYvAhoNO6S7PAvZs/4DWnRu
5QIDAQABo1MwUTAdBgNVHQ4EFgQUyFB6a1gMxXBZ8LVszL0IQhTz5KkwHwYDVR0j
BBgwFoAUyFB6a1gMxXBZ8LVszL0IQhTz5KkwDwYDVR0TAQH/BAUwAwEB/zANBgkq
hkiG9w0BAQUFAAOCAQEAovdgpHN5gi9BMTNspmart0EH8fG4aqNWGZUxEM/dsR9K
+aP7rA3MyKwzjxNzaH8tg9TOD6zaWAZIkNtPXCVkTp+9XEp7WE1fP0xcqZpJoxTI
bydPrvXvfk819xCivXttmsK0WgvBPfnM0V6ARMKpCTSzZsSLkEpBS8Z+3/2gWG07
q1fbiblpv1YxH+cEhA8gE2rbIWX/EleJxYFGFY6fUBi4ENHG3Wrbpgnmw9WWXuNs
NfbAlbwqA5blWu16rFpQUrkjqaF7FbChBjnvdGPOU+gcSmwAmH3M8bzxnfdGdW+2
kRz3p/JLF8ypivfkdUqYIW69cwuygcvlhbKaK31wtA==
-----END CERTIFICATE-----
Really need an android professional in this topic. I'm sure they are on the forum!
Damn, at first glance I was even glad that such an opportunity existed However, a more careful reading of the links clarified the situation - these mean the keys that are used to assemble the system by the manufacturer. I very much doubt that Rigol signed his Android build with a test key, which can be taken from the AOSP source code.
I looked at the certificate with which the Sparrow application was signed, and it is slightly different from the test ones.It was my impression that the test keys were supported by stock android, universally. Their very purpose is test and development -- so that you can install and test the app you develop as system app on any system without creating your own build of the OS. Of course you can't publish the app signed with them on google play etc.
I may be wrong. Really need an android professional in this topic. I'm sure they are on the forum!
Since we have root access on scope could be used scope to sign apk by itself?
I see an apk-signer on google play store, but there may be others too.Of course we can, it's not difficult at all. The problem is that we do not know the correct key that needs to be signed so that the application becomes trusted and can run under the system account and have privileged access to system resources. But there is a workaround - since we have root access, we can manually move the installed application to /system/priv-app after installation, which makes the application trusted and gives privileged access.
In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
<assign-permission name="android.permission.UPDATE_APP_OPS_STATS" uid="audioserver" />
<allow-in-power-save package="com.android.providers.downloads" />
I didn't find an example of how to put just the application name there.
As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.00.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.
As a side note, I was curious to see what Rigol had done with Sparrow. My scope is v00.01.00.00.00, I removed Sparrow and took Sparrow from a 00.01.02.00.02 GEL file and installed that. Installs just fine, but the only change that I notices was the whole RKey.data stuff. Nothing else appears to have changed, the scope runs exactly as it did before. I ran the zelea2 util to regen keys on the existing 914 vendor.bin.Starting from version 00.01.02.00.00, the calibration process has been changed. Calibration data is recorded in a different format and is larger in size. And starting with this version, the problem of vertical channel shift when upgrading an oscilloscope from DHO800 to DHO900 has gone away.
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.I looked at this file and found that it requires you to assign specific permissions to applications. For example:Code: [Select]<assign-permission name="android.permission.UPDATE_APP_OPS_STATS" uid="audioserver" />
<allow-in-power-save package="com.android.providers.downloads" />
In the Android model, only apps that run under same shared context (uid) can share data between the apps.
That said, if you park an app in app-priv running in some other uid context, that app still can't share data with other apps.
Does Sparrow apk need to share data with other apps and vice-versa? Might not be.
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
We won't be able to sign an edited APK to run under android.uid.system, but we can likely allow the app to do everything it needs to do. I wonder if the whitelisted permission allows the app to share data with other apps. Not 100% clear to me.
Android is based on Linux kernel and there are uid and gid. This second one is a id of a group. Anyway, I dont know how much its used, but it is.
Scroll down near end of file, there's a system app whitelisted permission. Just add another line there for com.rigol.scope
<!-- These are the packages that are white-listed to be able to run as system user -->
<system-user-whitelisted-app package="com.android.settings" />
As far as I understand, it may allow the application to run under the system account even if the application is not signed with a system key. I'll have to try it, thanks
Try adding a whitelisted system entry after the one in /etc/permissions/platform.xml, add "com.rigol.scope"
I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display
But the application still launched under the account of a regular user
FWIW, com.rigol.scope runs under uid 1000, whereas the processes run by root run under uid 0.
Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.
Edit: I hope you are keeping good records of all the changes you make. For a future new firmware, I assume you have to manually re-do them all over, right?
Even if You change executable uid? Have You tried to make "ugly" move with uid 0?
One very simple command to copy raw binary data from a serial block device - including SD cards:Code: [Select]cp /dev/sdb /home/userHomeDirectory/rawBinaryImageOfFancySDcardFromScope.fancyLongFileExtension
To be less fancy, I can use any graphical file manager in Linux to make exactly same thing.