yashsingh1/xdaforums huggingface dataset:
[Connected Car] Edenees:
I test it yesterday. From 1 to 5 it was oké. Step 6, rebooting starts and SCT reboot, but the cursus still pending.

After that, I am logon at play store and try install an app. Then, on the screen: pakket is not correct.
[Connected Car] RichieB:
Yes, thanks for testing. Can you try to replace services.jar as explained here?
[Connected Car] gekkekoe123:
in this order from safe to less safe

Overriding the property at boot with setpropex, replacing jar, replacing initrd

Download the attached setprop.zip

unzip, and adb push setpropex files to tmp folder.

adb shell

su to root

chmod +x the setpropex

now execute:

./setpropex ro.parrot.install.allow-all 1

check if property is set:

getprop ro.parrot.install.allow-all

should give true.

you should be able to install apks now.

If this works, we need to let this command run on boot, and problem should be solved.

[edit]

removed the .so libs in package, since it isn't required.
[Connected Car] RichieB:
I agree. Can you explain how to run setpropex at boot?
[Connected Car] gekkekoe123:
first check if it works, but there are a lot of scripts running at boot.

you could append the command to

/etc/init.parrot.sh

or

/etc/init.parrot.fc6100.sh
[Connected Car] donaldta:
That command is genius! I am definitely going to keep that one around. Thanks for pointing it out! :good:

$ [COLOR="RoyalBlue"][B]cat /default.prop[/B][/COLOR]
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
persist.service.macgyverd.anon=1
$ [COLOR="RoyalBlue"][B]getprop ro.secure[/B][/COLOR]
1
$ [COLOR="RoyalBlue"][B]su[/B][/COLOR]
# [COLOR="RoyalBlue"][B]setprop ro.secure 0[/B][/COLOR]
# [COLOR="RoyalBlue"][B]getprop ro.secure[/B][/COLOR]
1 [COLOR="Silver"]#failed![/COLOR]
# [COLOR="RoyalBlue"][B]setpropex ro.secure 0[/B][/COLOR]
# [COLOR="RoyalBlue"][B]getprop ro.secure[/B][/COLOR]
0 [COLOR="Silver"]#success![/COLOR]
#

I'd be interested to see where it is and how he did it as well.

$ [B][COLOR="RoyalBlue"]cat /proc/mtd[/COLOR][/B]
dev: size erasesize name
mtd0: 00080000 00020000 "Pbootloader"
mtd1: 01000000 00020000 "Pmain_boot"
mtd2: 00400000 00020000 "Pfactory"
mtd3: 3eb00000 00020000 "Psystem"
mtd4: 00080000 00020000 "Pmtdoops"
$ [COLOR="RoyalBlue"][B]ls -l /dev/block/mtdblock?[/B][/COLOR]
brw------- root root 31, 0 2014-03-02 11:46 mtdblock0
brw------- root root 31, 1 2014-03-02 11:46 mtdblock1
brw------- root root 31, 2 2014-03-02 11:46 mtdblock2
brw------- root root 31, 3 2014-03-02 11:46 mtdblock3
brw------- root root 31, 4 2014-03-02 11:46 mtdblock4
$

I guess it is one of these partitions? As for inside the plf file, it is probably encapsulated in the main_boot.plf

C:\SCT\v1.49.34\main_boot> dir
03/02/2014 12:49 PM <DIR> .
03/02/2014 12:49 PM <DIR> ..
03/02/2014 12:49 PM 411 bootparams.txt
03/02/2014 12:49 PM 299,903 initrd
03/02/2014 12:49 PM <DIR> UNHANDLED
03/02/2014 12:49 PM 2,898,900 zimage
3 File(s) 3,199,214 bytes
3 Dir(s) 2,452,205,568 bytes free

C:\SCT\v1.49.34\main_boot>

Unless I am mistaken, there isn't a way for us to repack .plf files at the moment.

---------- Post added at 01:08 PM ---------- Previous post was at 12:57 PM ----------

I am curious. Why did you include libc.so and libcutils.so in the attached archive? The command setpropex works with the stock version of those files already in /system/lib directory. Including them in the archive might lead someone to overwrite them in the stock directores which is NOT a good idea, since altering libc.so on a live system will halt it and end up bricking it.

Besides, the author was kind enough to share the source code and the pre-compiled, "setpropex", command on his Google Drive.
[Connected Car] gekkekoe123:
I didn't know if setpropex required those specific libs. So included them to be safe. But if it works with, then great no need supply those 2 libs.

The initrd file is the gz ramdisk. copy that file , gunzip, and then cpio -iv < unzipped_initrd

it will unpack the files, so you can examine. I also spotted that there's some kind of parrot recovery in there :)

We can modify and then cpio/gzip it back to initrd and put it back on the appropiate partition (I haven't looked where it is on the SCT, only examined the PLF). But for now setpropex isn't that bad and should gives us arbitrary apk install again :)
[Connected Car] donaldta:
It might be a good idea to change the post and attachment in case someone reading the single post doesn't "unknowningly" brick their SCT.

Nice, Thanks. After I ran plftool on the main_boot.plf, I used 7-zip on initrd which created the initrd~ archive. I used 7-zip again on that and it unpacked the initrd~~ directory.

It looks like in addition to the default.prop file that the initlogo.rle (startup static logo) is there as well.
[Connected Car] gekkekoe123:
Already modified the setprop so it's safe now. The contents of the scripts are intersting, one of them refer to a parrot_recovery.sh
[Connected Car] donaldta:
:good:

Yes, but that points to the same script on the system partition that has been there for a long time. I don't think that has much relevance to the "boot recovery" that you're thinking about. The only way I know how to initiate that is from via "Settings > About > Update product > Update by USB stick." and with the Parrot Asteroid Smart by constantly swiping two fingers on the screen during power up. I don't think anyone has figured a manual way to boot into the boot recovery for the SCT yet.
[Connected Car] mushroom62:
How not to brick SCT

Good evening, first of all many thanks to all you guys putting so much effort in putting some sense in my car. :good:

I declared my SCT useless last week when Volvo replaced google maps with Bing maps. If I understand correctly my SCT is now rooted. Only it will not allow other software to be installed because of the update. Is it now safe to push these services files to my SCT? Thanks in advance:confused:
[Connected Car] donaldta:
We're still in the testing phase for SCT's version 1.49.34 firmware. We still need to identify what works and to what extent. However, it is safe to copy the "setpropex" command into the SCT in order to alter the "ro.parrot.install.allow-all" value from "false" to "true" (temporarily). This should allow you to install apps until the SCT shutdowns or reboots. Before we can make this a little more "permanent", we still need someone to test and verify it. Unfortunately, I do not have a SCT to test it or I would have done it already.
[Connected Car] dongwenxuan:
Guys I didn't try that .jar file yet, a little bit scared to brick the sct.

Should I try this method first?
[Connected Car] donaldta:
Go ahead and use my instructions above your post in Post #1296.
[Connected Car] dongwenxuan:
OK. I'll take a shot and let you know if your method work.

---------- Post added at 05:20 AM ---------- Previous post was at 04:27 AM ----------

I got result here:

adb push setpropex /data/local/tmp
158 KB/s (13920 bytes in 0.086s)

adb shell
$ su
su
# chmod 755 /data/local/tmp/setpropex
chmod 755 /data/local/tmp/setpropex
# remount.sh system-rw feedback
remount.sh system-rw feedback
mount -o rw,remount -t ubifs ubi0:system /system
ubi0:system /system ubifs rw,relatime 0 0
# cp /data/local/tmp/setpropex /system/xbin
cp /data/local/tmp/setpropex /system/xbin
# rm /data/local/tmp/setpropex
rm /data/local/tmp/setpropex
# ls -l /system/xbin/setpropex
ls -l /system/xbin/setpropex
-rwxr-xr-x root root 13920 2014-03-02 23:17 setpropex
# getprop ro.parrot.install.allow-all
getprop ro.parrot.install.allow-all
false
# setpropex ro.parrot.install-all true
setpropex ro.parrot.install-all true
# getprop ro.parrot.install.allow-all
getprop ro.parrot.install.allow-all
false
#

It looks the last result is False, not True, which means I still cannot install apps, right?

I tired to pm install an app, here is what I got:# pm install ESFileExplorer.apk

pm install ESFileExplorer.apk
pkg: ESFileExplorer.apk
Failure [INSTALL_FAILED_INSUFFICIENT_STORAGE]
[Connected Car] gekkekoe123:
Weird. Could you test with 1 instead of true?

Could you also see if the init process is running with pid = 1 ? The tools assumes that.

adb shell
ps | grep init

should give something like this:
root 1 0 824 656 ffffffff 00000000 S /init

Also your install fails on not enough space, not invalid apks...

install a small apk < 7MB and see if it works
[Connected Car] dongwenxuan:
Do you mean setpropex ro.parrot.install-all true 1 ?

I realized that error message was different than "Invalid Package" this time. But the apk file I tried is only 3 mb.
[Connected Car] RichieB:
Yes, since setpropex patches the memory location of the properties you need to use the internal values. So 1 instead of true:

setpropex ro.parrot.install.allow-all 1

Also, when you tests fail it is always a good idea to send along the logcat output. This way we can determine what went wrong much faster.
[Connected Car] donaldta:
Yes, that's correct. Since setpropex is a native linux binary, we can use strace to see what it doing (trying). Next time, please perform the following commands so that we can get an idea of why it failed.

# [COLOR="RoyalBlue"][B]getprop ro.parrot.install.allow-all[/B][/COLOR]
false
# [COLOR="RoyalBlue"][B]strace -fo /mnt/sdcard/setpropex.txt setpropex ro.parrot.install.allow-all true[/B][/COLOR]
# [COLOR="RoyalBlue"][B]getprop ro.parrot.install.allow-all[/B][/COLOR]
true
# [COLOR="RoyalBlue"][B]cat /mnt/sdcard/setpropex.txt[/B][/COLOR]

Then attach the file in your reply so we can take a look at it

Actually, that's a poorly coded error routine / syntax error. You can also get that error if the APK isn't in the present working directory (pwd). In this case, I suspect that you hadn't changed into the directory where that APK exists or the filename was incorrect. If you didn't know before, you can always specify the path with the filename if you're not currently in the same directory. Also, since this is Linux, the filenames are case-sensitive.

Something, I do quite regularly is backup the installed APKs via Es File Explorer. So to install an APK regardless of the pwd, I use 'pm install "/mnt/sdcard/backups/apps/ES File Explorer_3.1.0.2.apk"'. I use double quotes to encapsulate the path and filename because Es File Explorer tends to use spaces in their backup names, whereas Linux acknowledges spaces as a delimiter for separate arguments.

If you do get an error other than "Failure [INSTALL_FAILED_INVALID_APK]" & "Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]", then we'll need logcat to get the full scope of the problem. Next time you get an unexpected error, please perform the the following commands:

$ [COLOR="RoyalBlue"][B]su[/B][/COLOR]
# [B][COLOR="RoyalBlue"]logcat -c; sleep 1; pm install ESFileExplorer.apk; sleep 20; logcat -df /mnt/sdcard/pminstall.txt[/COLOR][/B]

At that point, you can "cat /mnt/sdcard/pminstall.txt" to get an idea of the problem or attach the file in your next reply so that we can decipher it for you.

---------- Post added at 10:30 AM ---------- Previous post was at 09:59 AM ----------

Okay, I just double-checked your results and my instructions. It appears that I had a brain fart when composing the original instructions. It should have been "setpropex ro.parrot.install.allow-all true". I apologize for that. You might have inadvertently created a new system property by doing the last command. Don't worry, it is harmless and will go away on the next reboot / shutdown. But, can you repeat the instructions with the corrected syntax?
[Connected Car] RichieB:
I checked the source code of setpropex and it uses memcpy to update the properties. No translation is done on the command line values whatsoever. I highly doubt boolean properties in memory use "true" or "false", most likely they are stored as 1 or 0. So the command should be:

setpropex ro.parrot.install.allow-all 1
[Connected Car] donaldta:
Exactly! :laugh: Just kidding. I know what you meant but for this exercise I'd like to start off with the opposite of the current registered value.
[Connected Car] mushroom62:
SCT trial

I will give it try coming weekend and see if it works. Thanks. I'll keep up with this thread to see what else you guys discover.
[Connected Car] dongwenxuan:
I tried setting property to both "True" and "1", and tried pm install and app store install. Still no luck.

I've uploaded the pminstall.txt for you guys check.
[Connected Car] donaldta:
Well, according to the logcat:

W/asset ( 2161): Asset path /ESFileExplorer.apk is neither a directory nor file (type=1).
D/dalvikvm( 2161): GC_EXPLICIT freed 7K, 50% free 2726K/5379K, external 2801K/3132K, paused 33ms
E/DefContainer( 2161): Couldn't copy file: /ESFileExplorer.apk

The package that you specified was not there. It looks like you tried to install it from / which is read-only. I don't that apk was in that path.

Did you happen to get an strace of the setpropex command? Did it actually change or no?
[Connected Car] dongwenxuan:
I did put that apk file under \bin folder.

Confused about your second question. I didn't run strace this time.
[Connected Car] donaldta:
Why would you put it in the bin folder? That's a bit odd since it is read-only. My recommendation is to copy it to /mnt/sdcard and use "pm install" to install it from there. Because according to the logcat message, you specified, "pm install /ESFileExplorer.apk" not /bin. Also note, because this is Linux the correct slashes go / instead of like windows which goes \. Yes, it matters.

OOOOH! Wait, when you "adb shell" you've moved the command prompt into being inside of Linux on the SCT. It has no ideas of the files you have in "C:\(whatever)bin\". It can only access the files in the SCT's path. Next time before you use "pm install" use "adb push" beforehand to upload it into the SCT.

The top of Post #1303. Explains what we needed if it didn't work. So, that we can troubleshoot the problem. Btw, you ever mentioned whether or not "setpropex" flipped the value. Did you use "getprop" to check it afterwards?
[Connected Car] dongwenxuan:
I checked the value, it's true after setpropex.
[Connected Car] donaldta:
Well, it is good setpropex command worked but bad that it didn't address the problem. I'm guessing that service.jar only checks the value during init and doesn't refresh. You might have no choice at this point but to test the service.jar file. Though, I am not sure who's modified file you want to use at this point.
[Connected Car] gekkekoe123:
Next is have setpropex run on boot.

The init files are executed before android init. So it should give you apk install. Ensure that you run it as root on boot.

To all users. Do not update to any newer version than this. Next time we might not be this lucky.
[Connected Car] mushroom62:
Gekkekoe123, can you leave us a new set of instructions how to install apps on SCT, because I'am a bit lost now in how to do this succesfully. Best regards
[Connected Car] RichieB:
The instructions are here. When you can confirm this works we will make a new menu.bat to automate this.
[Connected Car] Edenees:
Good job, RicardB. When it is ready, I want to test it. I can't wait. ;)
[Connected Car] RichieB:
Perhaps you misunderstood: we need people with the latest firmware to test this solution first. When it works we will automate it so it will be easier to install.
[Connected Car] Edenees:
Sorry, I'm not that expert, to do that without a automatic menu.
[Connected Car] mushroom62:
Ok, I will give it a try this weekend. If this doesn't work, is it possible to downgrade the SCT and use the older PLF? And where can I get the old PLF. I will let you guys know if it does work.;)
[Connected Car] RichieB:
I have the PLF files for the EU versions: 1.47.88 and 1.47.96.
[Connected Car] gekkekoe123:
maybe I wasn't clear enough. The setpropex is working, so you need to add that command to one of the init scripts. Just pick one.

For example /etc/init.parrot.sh

at the end:

[ -f /system/etc/init.parrot.$(getprop ro.hardware).sh ] &&
. /system/etc/init.parrot.$(getprop ro.hardware).sh

#emulate post-freeze
start parrot-post

change to

[ -f /system/etc/init.parrot.$(getprop ro.hardware).sh ] &&
. /system/etc/init.parrot.$(getprop ro.hardware).sh

./system/xbin/setpropex ro.parrot.install.allow-all 1

#emulate post-freeze
start parrot-post

This assumes that you put the setprop binary in /system/xbin.

Those init scripts should be running as root, so no need to su run them. after reboot you should have apk install.
[Connected Car] RichieB:
I think you need to drop the . before /system (just in case the current directory is not /):

[ -f /system/etc/init.parrot.$(getprop ro.hardware).sh ] &&
. /system/etc/init.parrot.$(getprop ro.hardware).sh

/system/xbin/setpropex ro.parrot.install.allow-all 1

#emulate post-freeze
start parrot-post
[Connected Car] gekkekoe123:
You could do that, but my lines should work as well (parrot assumes scripts in root as well). Doens't really matter in this case.

I probably do the upgrade to the new firmware in the coming days.
[Connected Car] dongwenxuan:
I am confused. Should I try the .jar file method or this one?
[Connected Car] dongwenxuan:
The value did change to true but still failed install app through app store.
[Connected Car] donaldta:
Remember not everyone knows which one to pick. The optimal one to modify is the "init.parrot.capabilities.sh" script because that is the first one called by /init.rc which is the intial bootup script. I looked at the master_boot archive and saw that this line is the first external .sh file executed by the /init.rc file.

I propose the following modification to the "init.parrot.capabilities.sh" file :

#!/system/bin/sh
[COLOR="Red"][B]/system/xbin/setpropex ro.parrot.install.allow-all true[/B][/COLOR]

#capchecker come from lucie package
if [ -f /system/xbin/capchecker ] ; then

if [ ! -f /system/capabilitiesDone ] ; then
mount -o remount,rw /system /system

chown parrot /system/lib/udev/*

capchecker -i /system/xbin/*
capchecker -i /system/bin/*
capchecker -i /system/lib/udev/*

[ -f /system/etc/init.parrot.capabilities.product.sh ] &&
. /system/etc/init.parrot.capabilities.product.sh
#validate cap changes
sync
touch /system/capabilitiesDone

mount -o remount,ro /system /system
fi
fi

No, it does matter. You should not specify "." in front of the path if you do not know its present working directory. The leading dot would mean "from here".

Here is an example of why:

# pwd
/system/etc
# [COLOR="RoyalBlue"][B]ls -l [COLOR="Red"][B].[/B][/COLOR]/default.prop[/B][/COLOR]
[COLOR="Red"][B].[/B][/COLOR]/default.prop: No such file or directory
# [COLOR="RoyalBlue"][B]ls -l /default.prop[/B][/COLOR]
-rw-r--r-- root root 151 1969-12-31 18:00 default.prop
#

As usual, try my method first. Replace the stock "/system/etc/init.parrot.capabilities.sh" script with my modified version attached below.

C:\[COLOR="Silver"]{path\to\cmd-frama-menu\}[/COLOR]bin\> [COLOR="RoyalBlue"][B]adb push init.parrot.capabilities.sh /data/local/tmp/[/B][/COLOR]
C:\[COLOR="Silver"]{path\to\cmd-frama-menu\}[/COLOR]bin\> [COLOR="RoyalBlue"][B]adb shell[/B][/COLOR]
$ [COLOR="RoyalBlue"][B]su[/B][/COLOR]
# [COLOR="RoyalBlue"][B]chmod 770 /data/local/tmp/init.parrot.capabilities.sh[/B][/COLOR]
# [COLOR="RoyalBlue"][B]chown root.shell /data/local/tmp/init.parrot.capabilities.sh[/B][/COLOR]
# [COLOR="RoyalBlue"][B]/system/xbin/remount.sh system-rw[/B][/COLOR]
# [COLOR="RoyalBlue"][B]cp /data/local/tmp/init.parrot.capabilities.sh /system/etc/.[/B][/COLOR]
# [COLOR="RoyalBlue"][B]ls -l /system/etc/init.parrot.capabilities.sh[/B][/COLOR]
-r-xr-x--- root shell [COLOR="Silver"]{size} {date} {time}[/COLOR] init.parrot.capabilities.sh
# [COLOR="RoyalBlue"][B]rm /data/local/tmp/init.parrot.capabilities.sh[/B][/COLOR]
# [COLOR="RoyalBlue"][B]reboot[/B][/COLOR]

---------- Post added at 12:49 PM ---------- Previous post was at 12:43 PM ----------

The conjecture here is whether or not the service.jar file reads the system property for "ro.parrot.install.allow-all" once during Android's initialization. We're proposing to actuate the alteration by modifying the init scripts which are read before Android during Linux's initialization.
[Connected Car] gekkekoe123:
Actually it was fine (since we are in the root folder), but since I was too lazy, I used your file. I had to correct the "true" to 1.

I also changed the menu to do this. I removed the set prop option, it's not needed anymore. Setpropex should also work on older versions.

Btw, I did the upgrade manually using adb shell, and did not used the menu.bat.

So if anyone could test it or double check the menu.bat file, it should be fine. I translated the manual commands back into the menu.bat

My SCT is upgraded and I am able to install apks :) Let's find out if waze lost of data is fixed. Also adjusting screen dpi is still working. But we now have setpropex so we can override everything ;)

When you finished step 5, you need to reboot in order to be able to install apks.

As allways: no guarantee and at your own risk when using the tools
[Connected Car] RichieB:
Great, thanks! I might do the upgrade next Friday. Or maybe not.. there is not a lot that changed, so I have little incentive.
[Connected Car] dongwenxuan:
I think when running your code, there is an error?

# chown root.shell init.parrot.capabilities.sh

chown root.shell init.parrot.capabilities.sh

Unable to chmod init.parrot.capabilities.sh: No such file or directory

---------- Post added at 09:08 PM ---------- Previous post was at 09:07 PM ----------

I tested, the bat file is not working.
[Connected Car] gekkekoe123:
did you do all step?

you need to remount system as RW and then install the setprop and overwrite init file

run 2 and then 5 and reboot.
[Connected Car] donaldta:
Yes, sorry I slipped and did not specify the full path, the command should be "chown root.shell /data/local/tmp/init.parrot.capabilities.sh"
[Connected Car] dongwenxuan:
I think now it's working?

After reboot, I tried adb install apk:

adb install ESFileExplorer.apk
176 KB/s (3949826 bytes in 21.893s)
pkg: /data/local/tmp/ESFileExplorer.apk
Success
[Connected Car] gekkekoe123:
So you needed to reboot ;) good thanks for testing. We now know that the menu.bat is working ;) enjoy!
[Connected Car] dongwenxuan:
Yes, the method [MENTION=5389783]donaldta[/MENTION] provided works!

But your new menu.bat didn't work, maybe need some change?

Actually I didn't have a chance to see if the apps really be installed or not. Since I am using remote start to run the car (it can start the car for 15 mins) and use my laptop indoor.

I'll make sure it later today.
[Connected Car] gekkekoe123:
I actually think the menu.bat worked, but you just needed to reboot.

I did not needed to chown any files on my system. Since at boot the init scripts are ran with root permissions.
[Connected Car] donaldta:
Thanks for checking it for me.

No worries. I'll be rewriting the menu.bat and should have the actual updated one I had promised last year. It should be ready by Friday. And don't worry, I personally test my scripts before releasing it to the public.

---------- Post added at 02:26 PM ---------- Previous post was at 02:21 PM ----------

You may not have needed to chown; however, I like to change the ownership and permissions back to the original state in case there are any gotchas down the road. Especially, since the original permissions is r-x (owner: root), r-x (group: shell) and others --- (none).
[Connected Car] gekkekoe123:
I actually tested the .bat but, since my system was already working, there was no 100% certainty and I wanted some eyes to double check.

With regards to the file permissions, It doesn't hurt to set the correct owner, but not really needed.

But you can correct it with your updated .bat :)
[Connected Car] donaldta:
You say, "its not really needed" because you're only looking at the script being ran during init. That's fine because that was the focus of the current hurdle. However, the script can might need to be re-ran by other processes or other users within the shell group at a later time for different reasons. If those process' users are not also in the root group then the script will fail due to the lack of permissions. That's why it is always better to be safe than blasé and shortsighted.