As I sit here at work my mind start to think. There is a host file on the Nook Color that is used just as the host file on a Windows machine is used. The Nook Color can auto update itself with out knowledge of the user. Why not monitor the ip address the Nook Color downloads the Side Loader update zip file from and block that address in the host file? That is better then renaming the OTACert file and if the site isn't found by the device the device will not try and update its self.
I thought of it now one of you go figure it out....here is what you have to do;
1. Make sure your on 1.0.0 firmware on the B&N Nook
2. Run Monitoring program on your router to see incoming data and what IP's are being utilized.
3. Run WIFI on Nook
4. Look for new data (side loader being downloaded from B&N)
5. Block that IP address in the hosts file
6. Reboot nook and see if it still tries to update its self.
Post back results.
2nd Idea:
I also though of putting a empty Sideload_update.zip in the root of the device and giving it no access rights through adb or root explorer.
Nice though I heard it leads to authentication errors when you the store... which in turn leads to your nook reverting back to 1.0.0.
mtl171 said:
Nice though I heard it leads to authentication errors when you the store... which in turn leads to your nook reverting back to 1.0.0.
Click to expand...
Click to collapse
I thought that was renaming the OTACert file. I also though of putting a empty Sideload_update.zip in the root of the device and giving it no access through adb.
xboxexpert said:
I thought that was renaming the OTACert file. I also though of putting a empty Sideload_update.zip in the root of the device and giving it no access through adb.
Click to expand...
Click to collapse
Aparently you can not chmod anything in /media folder
I renamed the otacert file and have been on 1.0 for several weeks now without any update.
wvcachi said:
I renamed the otacert file and have been on 1.0 for several weeks now without any update.
Click to expand...
Click to collapse
That works good but what if i wanted to stay on 1.0.1 with out updating...
How come some people get the auto update and some don't? I've been on 1.0 since before Christmas and haven't been forced into an update. I've even been sitting in B&N for hours at a time.
xboxexpert said:
That works good but what if i wanted to stay on 1.0.1 with out updating...
Click to expand...
Click to collapse
1.0.1 is the newest update, so there's nothing to update at this point. Unless they changed something, I'm guessing the otacerts method would probably work for future updates as well.
wvcachi said:
1.0.1 is the newest update, so there's nothing to update at this point. Unless they changed something, I'm guessing the otacerts method would probably work for future updates as well.
Click to expand...
Click to collapse
If you rename OTA in 1.0.1 and try and use the BN Shop or what not it will knock you out and reformat your nook. I'm looking to just block the update site via host file.
xboxexpert said:
If you rename OTA in 1.0.1 and try and use the BN Shop or what not it will knock you out and reformat your nook. I'm looking to just block the update site via host file.
Click to expand...
Click to collapse
It looks like that was based on one post that the poster later attributed to something else (read thread http://forum.xda-developers.com/showthread.php?p=10390633#post10390633).
So I see no reason not to disable otacerts on any firmware right now.
Well as I'm sure most of you know we released CM7 alpha for the NT on Sunday and it was very warmly received, even after a major bug was found it was still downloaded almost 2000 times by the time I eventually removed the files form download server yesterday (links were removed form thread at about 1200 downloads lol). The feedback is still extremely encouraging and people are itching for the next release.
We’ve been working hard on fixing everything so that the next version we release has a lot less bugs, we’ve fixed the main bug of formatting the xloader and we've fixed a handful over other things causing issue too.
The issues we are having now which we are struggling with are usb sync for media as well as sdcard to a computer (in another thread) and a more important one of market not being able to install larger games / programs if there is an sdcard in. For instance one that I use for testing is Zombie bash, if you have an sdcard in it just won't install.. We've looked up the error online and all the errors point towards deleting a certain file but the problem is that we don't actually have that file so it would appear we have a different issue!
So the time has come for Goncezilla and I to reach out and ask for help, somebody out there probably knows or can debug and find out what the issue is. We're stumped and we don't want to release the next version until that’s fixed!
So please, if anybody can help, drop me a Pm or say something on here and lets get CM7 next alpha version sorted and released !
Is there any way to get an error log of this issue? I am using an app called LogThis and nothing is shown in Logcat.
Probably totally unrelated but on the stock ROM I grabbed a couple of Amazon Freebies the weighed in over 50Meg's each. I wasn't even really interested in them so I carried on about my business and a couple of days later noticed that they never installed. After digging around the "error" was that I DIDN'T have an SD card installed. This struck me as weird because the 1GB user and 12GB B&N partitions should have certainly been enough.
Either way once I popped in an SD card the downloads automatically started and off I went.
Like I said .... probably useless information but I figured I would throw it out there.
arclite00 said:
Is there any way to get an error log of this issue? I am using an app called LogThis and nothing is shown in Logcat.
Click to expand...
Click to collapse
Good point, HERE is the logcat.
Mainly it would appear the errors showing are
E/Vold ( 1168): Error opening devmapper (No such file or directory)
E/Vold ( 1168): ASEC device mapping failed (No such file or directory)
and then a few lines on
E/PackageHelper( 2146): Failed to create secure container smdl2tmp1
E/DefContainer( 2146): Failed to create container smdl2tmp1
any help to anybody ?
I'm not too versed in the world of Android development, however this might be useful. LINK 1 LINK 2
Perhaps the permissions to the folders referenced in these articles are incorrect...
scsione889 said:
I'm not too versed in the world of Android development, however this might be useful. LINK 1 LINK 2
Perhaps the permissions to the folders referenced in these articles are incorrect...
Click to expand...
Click to collapse
Thanks for trying, that's one of the articles we found but unfortunately we couldn’t get anywhere with it
From the log it appears as though it is unable to create the smdl2tmp1 temp file. So wouldn't it make sense that it would either be permissions of the folder it's going in, or an issue with whatever is trying to create that temp file?
Have we tried not pre-packaging gapps with the ROM to see if that helps?
Quick question, is there a specific file size where the install fails\hangs? Ex installs are okay up to 9 meg files, but anything over, and it fails?
I want to try and download something and replicate the issue.
Disregard...
I had no problem installing Google Earth and other large apps (over 8MB) today, but cannot install Zombie Dash (only 4 and some change) moments ago. Not sure what relavence the size of the app might be having with the install issue...
Sent from my BNTV250 using xda premium
I found that the "/mnt/sdcard/.android_secure" folder has 000 permissions. The other folder mentioned in the links I posted (/mnt/secure/asec) has 075 permissions.
I compared this to my phone with fully functional market and found "/mnt/sdcard/.android_secure" has 000 permissions. The asec folder has 175 permissions. Perhaps the execute permissions is the problem? I am unable to change permissions in root explorer to test. I get the "some file systems (e.g. SD card) do not allow permission changes" message.
You considered posting on the Android development section? They may have some more info or guidance with this.
Sent from my Nexus S using Tapatalk
I'm not thinking it's permissions I think we've messed up and something isn't tuned on in kernel like driver mapper or asec.
Just been unable to find it. Although I'm speaking to somebody now and I think he may have hit on the cure
Okay...
"Size of container 7 MB 5392635 bytes"
I am assuming based on that, that the app is 7 meg?
D/Vold ( 1168): DEVPATH='/devices/virtual/block/loop0'
D/Vold ( 1168): DEVTYPE='disk'
D/Vold ( 1168): MAJOR='7'
D/Vold ( 1168): MINOR='0'
E/PackageHelper( 2146): Failed to create secure container smdl2tmp1
Okay, sp if you eject the SD card, the download works and installs. So that means when you go to download the app, it creates a temp file (same as when you download a file in windows via your web browser), and then once the download completes, the temp file is removed and you have an apk which is automagically installed via android app handler or whatever. IF the SD card is inserted, it tries to create the file on the SD card instead of internal memory. So the issues lies with the SD card itself possibly(?). Have you tried running checkdisk or some disk checking tool on your card? I have had issues in the past where my sd card got corrupted (once after running the partitioning tool in cwm) and I couldn't install large market apps. I ran checkdisk and found errors (i cant remember the exact msgs), but I repartitioned the card and all was well. It is possible with all the partitioning etc you have done to your cards, they have gotten a bit screwy, have you tried swapping out the SD card for a different one?
I just installed gun bros which is a 12meg app, with my sd inserted and mounted, with no issues...I tried to view it in logcat as soon as I hit download, but I didn't see anything pertaining to the market download and install =(
I already re-partitioned my card and went out and bought a new card to try. It's not that.
CWS - Glad to hear you're making some potential progress.
Well, I've done my best to collect info on the error, so based on what others have found, this seems to be what I've learned so far, including the obvious.
-The error we're seeing is "Couldn't install on USB storage or SD card."
-This error seems to have been most often encountered by people using Android 2.2 (Froyo) and derivatives because that version was related to reading a temporary file called "smdl2tmp1.asec." The user workaround in 2.2 was to browse your SD card using ES File Explorer (so that you can see .folders, which are normally hidden), finding the file in either:
/sdcard/.android_secure/smdl2tmp1.asec
OR:
/mnt/secure/asec/smdl2tmp1.asec
and deleting it.
-This apparently has been fixed in 2.3 (Gingerbread). Because Cyanogenmod 7 uses 2.3.4 as a base, it's odd that we're still having this problem then.
So in my exploration of this stuff, here's what I found:
/sdcard/.android_secure has ZERO FILES in it. Ditto for /mnt/secure/asec. On my HTC Hero, both contain plenty of files with .asec extensions. I have no idea what these files are for, but I'm getting the impression that the reason why these .asec files are not appearing has to do with how the current ROM is treating the SD card.
Also, the error doesn't seem to have anything to do with install size. I've tried to install Minecraft Pocket Edition before, it's only 1.57 MB but it will get the error regardless.
Keep in mind that I'm not a programmer, but this is all I've been able to gather.
---------- Post added at 05:52 AM ---------- Previous post was at 05:49 AM ----------
[/COLOR]
Mike_IronFist said:
Well, I've done my best to collect info on the error, so based on what others have found, this seems to be what we know so far, including the obvious:
-The error we're seeing is "Couldn't install on USB storage or SD card."
-This error seems to have been most often encountered by people using Android 2.2 (Froyo) and derivatives because that version was related to reading a temporary file called "smdl2tmp1.asec." The user workaround in 2.2 was to browse your SD card using ES File Explorer (so that you can see .folders, which are normally hidden), finding the file in either:
/sdcard/.android_secure/smdl2tmp1.asec
OR:
/mnt/secure/asec/smdl2tmp1.asec
and deleting it.
-This apparently has been fixed in 2.3 (Gingerbread). Because Cyanogenmod 7 uses 2.3.4 as a base, it's odd that we're still having this problem then.
So in my exploration of this stuff, here's what I found:
/sdcard/.android_secure has ZERO FILES in it. Ditto for /mnt/secure/asec. On my HTC Hero, both contain plenty of files with .asec extensions. I have no idea what these files are for, but I'm getting the impression that the reason why these .asec files are not appearing has to do with how the current ROM is treating the SD card.
Also, the error doesn't seem to have anything to do with install size. I've tried to install Minecraft Pocket Edition before, it's only 1.57 MB but it will get the error regardless. Of course, ejecting my SD card or unmounting it temporarily allows me to install the app, but that doesn't fix the bug, does it?
Click to expand...
Click to collapse
You think some apps check for those .asec files, and since they don't find them, it fails some kind of authentication and bombs out the installation?
Actually, I just checked my shift, and those folders are all blank as well. Hopefully whomever Celtic is talking to knows what's up.
stealthfx said:
You think some apps check for those .asec files, and since they don't find them, it fails some kind of authentication and bombs out the installation?
Click to expand...
Click to collapse
Yeah, essentially like that. Further down that rabbit hole is what Celtic mentioned:
CelticWebSolutions said:
I think we've messed up and something isn't tuned on in kernel like driver mapper or asec.
Click to expand...
Click to collapse
Apps don't seem to be creating .asec files anywhere, and it seems like some apps need .asec files to validate certain information. It seems to have less to do with the size of the app and more with whether or not the app needs to check an .asec file to install or function.
Mike_IronFist said:
Yeah, essentially like that. Further down that rabbit hole is what Celtic mentioned:
Apps don't seem to be creating .asec files anywhere, and it seems like some apps need .asec files to validate certain information. It seems to have less to do with the size of the app and more with whether or not the app needs to check an .asec file to install or function.
Click to expand...
Click to collapse
/dev/block/vold/179:17 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
sould be
/dev/block/vold/179:10 (< Check on that) /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
also im looking into the fact that /device/virtual/block/loop0 does not exist.
stealthfx said:
Quick question, is there a specific file size where the install fails\hangs? Ex installs are okay up to 9 meg files, but anything over, and it fails?
I want to try and download something and replicate the issue.
Click to expand...
Click to collapse
I think the filesize problem is a red herring. It looks to be apps that have "'android:installLocation="preferExternal" in their apk manifest file.
Obviously this is probably used on larger apps more often so it looks like it is tied to the filesize. I have some small apps that give the same error.
Checkout http ://developer.android.com/guide/appendix/install-location.html for more info.
This doesn't necessarily help with the original problem but it might help limit the scope of troubleshooting.
Hi,
I'm a dev working on Mozilla's Boot2Gecko project. We've run into an issue with heimdall, and I'm trying to get ahold of the dev to discuss this further.
One of my coworkers created an issue on github, and I've added some comments, but neither one of us has received any replies, so I'm posting here to see if that helps.
The problem that we've run into, is that I can use heimdall fine when our system.img file is 100Mb or less, but get failures or corruption when system.img is 100Mb or larger.
My phone is a Samsung GT-I9100 (Samsung Galaxy S II). I upgraded the firmware to ICS using the XXLPQ firmware (I used this page: www dot theandroidsoul dot com slash xxlpq (the form won't let me post the url since I've posted less than 8 times), so its possible that the problem is related to newer bootloaders.
I have a system.img file that is 115Mb, and the command line I use is:
heimdall flash --factoryfs system.img
Under 1.3.1, there is a noticable pause at 87%, then it continues on to 100% and reports success, but the image that is burned into flash is corrupted.
Under 1.3.2, it stops at 87% and reports a failure.
Running with --verbose, the 87% corresponds to 800 packets of 128K each (which is 100 Mb)
If I reduce system.img to under 100 Mb, then both 1.3.1 and 1.3.2 work fine.
My dev machine is running Ubuntu 12.04, and I have a Windows 7 VirtualBox. I see the same behaviour from the Windows 7 VM as I see from ubuntu.
If I use odin (v1.83) from the Windows 7 VM, then it burns it properly.
I took a quick look at the source code and tried increasing the 800 limit (kMaxSequenceLength) and the 128K limit (kDefaultPacketSize), but those both fail as well.
I have packet wireshark captures of the USB streams under linux, and I installed a trial version of USBlyser under windows and have packet captures from both odin and heimdall, should those prove useful.
From the packet captures, odin seems to be transferring 1Mb at a time.
I had the same problems with my ET4G. I posted a pull request on the project's github. I'd link you there but I am not allowed since I am a new user, it is pull request #47. Works for me... maybe it will help you out.
bleffij said:
I had the same problems with my ET4G. I posted a pull request on the project's github. I'd link you there but I am not allowed since I am a new user, it is pull request #47. Works for me... maybe it will help you out.
Click to expand...
Click to collapse
this is certainly not fixed for me for an SHW-M250K (korean SGS II and compatible with I9100 ROMS with minor caveats).
I get extremely similar symptoms(identical as far as I can tell): Consistent corruption where files don't diff against the loopback mounted ROM files and are reprodicibly corrupt for any particular ROM. I saw this on.. I think it was 1.3.2 and then grabbed the latest 1.4RC1 from git and still see the same thing. Flashes with odin on the same hardware in fact in a windows vm within the same host OS.. work just fine. This is really bad especially since, sometimes the corruption isn't that obvious.
It seems to be scattered bits or bytes. Often the system boots but encounters various amounts of bugginess (depending on the EXACT rom, just adding or removing a file from the rom not surprisingly changes which bits and bytes are corrup)t. I guess it's many small chunks that are corrupt because I see typically maybe 80% of files are corrupt but still things kind of work. That tells me it's like a bit byte or small chunk here or there for every few MB probably. Enough to get most files but little enough it doesn't get every file or break them entirely.
I don't have a github account. Maybe I need to make one.
https://pastebin.com/kjWGUXkj
Building on a 2.4ghz i5 with 4GB RAM (and 4GB swap) on Ubuntu 16.04.3.
I followed the steps on the LineageOS build wiki here
https://wiki.lineageos.org/devices/shamu/build
What am I doing wrong?
wrsg said:
https://pastebin.com/kjWGUXkj
Building on a 2.4ghz i5 with 4GB RAM (and 4GB swap) on Ubuntu 16.04.3.
I followed the steps on the LineageOS build wiki here
https://wiki.lineageos.org/devices/shamu/build
What am I doing wrong?
Click to expand...
Click to collapse
Missing vendor files perhaps.
Elektroschmock said:
Missing vendor files perhaps.
Click to expand...
Click to collapse
Thanks, I found the Tycho.apk from here
https://github.com/TheMuppets/proprietary_vendor_motorola/tree/cm-14.1/shamu/proprietary/app
Does it matter if the app version doesn't exactly match up with the build version?
Getting a similar crash with GCS.apk, I've found a file on github again and just preparing to brunch it again.
wrsg said:
Thanks, I found the Tycho.apk from here
https://github.com/TheMuppets/proprietary_vendor_motorola/tree/cm-14.1/shamu/proprietary/app
Does it matter if the app version doesn't exactly match up with the build version?
Getting a similar crash with GCS.apk, I've found a file on github again and just preparing to brunch it again.
Click to expand...
Click to collapse
Just add the repository to your local_manifest.xml. There is a lineage-15.0 branch too.
Another crash, this one makes less sense than the missing vendor apks
https://pastebin.com/Ywkwhq8Y
Jack dies from time to time on low-end systems with not enough RAM. Often it compiles if you restart the build.
Should I restart from 'brunch shamu'?
I've tried twice now, it's not looking good
https://pastebin.com/FMtmmLkD
are you using themuppets repo? i just did a build without errors.
k1l said:
are you using themuppets repo? i just did a build without errors.
Click to expand...
Click to collapse
No, I'm just following the LineageOS wiki and pulling straight from the LineageOS github. How much RAM do you have? Does jack-server start automatically for you, and how much RAM are you giving to it? The last few errors/crashes have been to do with the jack-server. When I do jack-diagnose, it said no crashes detected
see https://gist.github.com/fourkbomb/261ced58cd029c5f7742350aafdd9825 with this you dont have to pull the device stuff manually from the device or get the drivers manually somewhere else.
i am giving jack 6GB ram, i have plenty more. but i also export a custom TMPDIR since i needed that on my older building machine.
tested the build last night, worked so far. just had some issues with apps wanting root. supersu didnt seem to work proplery.
k1l said:
see https://gist.github.com/fourkbomb/261ced58cd029c5f7742350aafdd9825 with this you dont have to pull the device stuff manually from the device or get the drivers manually somewhere else.
i am giving jack 6GB ram, i have plenty more. but i also export a custom TMPDIR since i needed that on my older building machine.
tested the build last night, worked so far. just had some issues with apps wanting root. supersu didnt seem to work proplery.
Click to expand...
Click to collapse
I already pulled the drivers, I don't think that was the problem. I've been trying to give more and more memory to the jack VM (I'm now trying 6GB also). How much RAM do you have? Can this be done with 8GB?
So @chineel gave me a tip about doing kill-server on the jack vm between crashes, that really helped and it's nearly done with the build now I think.
Just 2 days ago Entrust published an update to their app containing a new native root checker, looking quickly at it, it seems like librootcheck-lib.so was just added in this new version, but isn't present in the previous 3.5.4.14 release.
APKPure still has the old version and downgrading seems to do the job for now.
https://apkpure.com/entrust-identityguard-mobile/com.entrust.identityGuard.mobile/versions
You can also of course use the identityguard tools to generate your token directly.
https://github.com/ss23/entrust-identityguard-tools
The following functions appear to exist for root checking in it, I haven't investigated which if any is failing yet, but if someone wants to speculate, feel free:
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isAccessedSuperuserApk
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isDetectedDevKeys
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isDetectedTestKeys
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundBusyboxBinary
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundDangerousProps
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundHooks
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundResetprop
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundSuBinary
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundWrongPathPermission
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundXposed
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isNotFoundReleaseKeys
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isPermissiveSelinux
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isSuExists
Just wanted to let everyone know that the downgrade should work if you do experience this issue this morning and see if anyone has ideas for how to bypass this if needed in future versions of the app.
EDIT:
I determined the reason mine was failing, a busybox installer must have created /data/local/busybox, if you have that directory existing, you may need to remove it to get IdentityGuard to start.
ultramancool said:
Just 2 days ago Entrust published an update to their app containing a new native root checker, looking quickly at it, it seems like librootcheck-lib.so was just added in this new version, but isn't present in the previous 3.5.4.14 release.
APKPure still has the old version and downgrading seems to do the job for now.
https://apkpure.com/entrust-identityguard-mobile/com.entrust.identityGuard.mobile/versions
You can also of course use the identityguard tools to generate your token directly.
https://github.com/ss23/entrust-identityguard-tools
The following functions appear to exist for root checking in it, I haven't investigated which if any is failing yet, but if someone wants to speculate, feel free:
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isAccessedSuperuserApk
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isDetectedDevKeys
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isDetectedTestKeys
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundBusyboxBinary
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundDangerousProps
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundHooks
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundResetprop
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundSuBinary
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundWrongPathPermission
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isFoundXposed
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isNotFoundReleaseKeys
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isPermissiveSelinux
Java_com_entrust_identityGuard_mobile_sdk_rootcheck_JniNativeRootCheck_isSuExists
Just wanted to let everyone know that the downgrade should work if you do experience this issue this morning and see if anyone has ideas for how to bypass this if needed in future versions of the app.
EDIT:
I determined the reason mine was failing, a busybox installer must have created /data/local/busybox, if you have that directory existing, you may need to remove it to get IdentityGuard to start.
Click to expand...
Click to collapse
Well just got the same problem, i dont have busybox and it still dont want to load, the old version works though, so theres that... thanks for the sugestion.
Edit: unfortunately playstore keeps updating the app... Tried the detach module, but it does not work with magical canary builds, Don't know what else to try.