Note: To skip the following lengthy background information, skip down to the numbered steps below.
Package disablers from a Vietnamese developer "Kunkunsoft" have popped up in the Play Store under various names as this poor (and clearly very bright) guy plays "whack-a-mole" with Google and Samsung. Neither company is happy about Kunkunsoft's "Swiss Army Knife" ability to efficiently disable individual services associated with system apps and to thus selectively limit telemetry while maintaining app functionality, especially without root. The routine is that a newly-named Kunkunsoft package disabler appears in the Play Store, sometimes with a plugin listed with a covert developer name that is not Kunkunsoft, becomes popular, and the developer is harrassed by the big guns until they finally force him to modify his app/plugin to delete the capability of disabling individual services and/or they take his app down. Its a sad situation.
The last no-root incarnation of the Kunkunsoft app ("BK Disabler for Samsung" with "BK Plugin v2") disappeared about 6 weeks or so ago. It is now replaced by "Service Disabler" which requires root. I am writing this "how-to" mainly for any users of BK Disabler for Samsung (no root) who may disable some boot-critical system package or service like I did and be stuck with the spectre of data and cofiguration loss. I spent way too much time trying to figure out how Kunkunksoft disables packages and services without root, in order to try to recover my phone by undoing his magic from a custom recovery. To his credit the dev responded to my email for assistance. However, he merely insisted that I would need to factory reset and lose my data and would provide no clue about how his app operates.
After much trial and tribulation I figured out how the app works and why it cannot be undone. BK Disabler implements its services control magic without root by skillfully exploiting a subset of Samsung's home-grown security system, Knox. Specifically, the app operates as a Samsung Enterprise Mobile Device Management ("MDM") manager. Normally an MDM manager sits on a corporate server and allows IT personnnel to create and distribute device policies to Samsung phones. But BK Disabler is an Android app that is also an MDM manager, both running on the phone and controlling the phone! Pretty clever, huh? More specifically, BK Disabler creates a protected Knox MDM container, turns on Kiosk-mode in the phone, and allows only apps/services that have not been disabled to run in that Kiosk environment! This is all done in real time, so the user is unaware that every time he/she disables or re-enables an app or service, BK Disabler actually goes into MDM management mode and modifies the Knox Kiosk mode container! As you can see, the dev is very clever and engages in substantial recursive thinking to pull this off! He also had to purchase a Knox MDM Management license from Samsung. That is why the app is called "BK Disabler for Samsung." It only works on Samsung devices because Samsung, in an effort to capture the corporate market, has placed this powerful control mechanism in the hands of the corporate world, giving corporations the power to implement controls that are otherwise unavailable without root. You can also see why it would likely be near-impossible to undo BK Disabler's freezes from a recovery environment. You would need to break into Ft. Knox... (I was actually surprised to find that I could read an SqLite database containing signed lists of the packages that I had disabled. I thought about editing the unencrypted database but finally gave up after realizing that it was a Knox MDM setup. The disabled system apps/services preventing boot were protected in a Knox container and boot would have failed before my edited database could have been read by BK Disabler, if at all.
With that way-too-lengthy background in place, this is the way to recover should you become too aggressive with BK Disabler for Samsung or any other package disabler for that matter:
Notes:
(a) I tested the method described only on my ancient Samsung Galaxy S5 running "Marshmallow" (Android 6.0.1). The BK Disabler (Samsung) app will only install on Samsung models which include the older Samsung Knox security system and Enterprise MDM included in the stock ROMs. That said, this recovery procedure is generalized to recover data from any phone that is flashable using Odin, which can accept a flash a version of TWRP applicable to the phone and which can be rooted.
(b) Its a good idea to have the back cover of the phone loose because you will need to pull the battery during this procedure. If you have a phone without a removable battery, I'm not sure how you can turn the phone off following an Odin flash, as I have no experience with a phone without a removable battery. Turning the phone off after flashing TWRP is necessary to prevent TWRP from being removed by an automatic boot to the OS after the TWRP flash. The first boot following a TWRP flash must be to recovery and not to system in order to make TWRP "stick."
(1) Note that flashing TWRP in this step will set the warranty bit on Samsung phones, which allegedly voids the Samsung warranty. Whether or not doing so actually legally voids the warranty varies according to consumer protection and contract laws of various jurisdictions. Boot into download mode (hold volume down and home button while pressing power button.) Using Odin (I used v3.13.1), flash TWRP 3.2.1-0 KLTE. Make sure that Odin recognizes your phone. It will show up in the upper-left window "ID:COM." Press the middle tab and unselect "automatic reboot." The reason is that your initial boot following the flash must be into recovery; otherwise TWRP will be deleted by the normal system boot process. TWRP fixes this problem when you first boot into TWRP recovery. Press the "PDA" button and navigate to the TWRP flash file. After the TWRP flash loads into Odin ("ready"), press start. You will see a message in the upper left window that the flash completed successfully. Pull the battery to turn the phone off. Re-insert battery.
(2) Boot into recovery (hold volume up and the home button while pressing the power button); you will see the TWRP recovery screen. TWRP recovery is a work of art!
(3) TWRP recovery will mount both the internal and external SD cards as MTP devices, allowing you to see all of your user folders and files on both SD cards in Windows Explorer.
Note: FYI for noobs, the "internal SD card" is a portion of internal flash memory within the Android Linux /data partition that is allocated for user storage. The "external SD card" is an actual microSD card plugged into the slot above the SIM card and just above the top edge of the battery. Generally speaking, when Android refers to "SD card" it is referring to the internal SD card and not to a microSD card that you plug into the phone above the battery.
(4) In Windows Explorer, copy and paste all folders from both internal and external SD cards to a safe place on your desktop PC, laptop, etc. Note that you do not even need TWRP to perform this operation for the external SD card because you can take the microSD card out of the phone and transfer the files from an external microSD card reader.
(5) Now we will create a nandroid backup of the entire system, all Android Linux partitions. The reason that we copied the SD card data using Windows Explorer is that a TWRP nandroid backup does NOT include either internal or external SD card data. All bits of all other partitions are included in the TWRP nandroid backup. The TWRP folks consider us to be smart enough to copy our photos, videos documents, etc. from both internal and external SD cards using Windows Explorer. However that still leaves lots of our data, like our contacts, calendars, text messages, emails, phone call logs, etc. buried in the nandroid backup.
(6) In TWRP, select the external SD card as the backup destination (if you don't have an external SD card, go buy one before doing anything else. Format it to fat32 in a USB card reader plugged into a Windows system (separate from the phone). Then insert the microSD card into the phone above the SIM card.
(7) In TWRP, select all partitions to back up, with the external SD card selected as the destination to write the nandroid backup to.
(8) Swipe the indicated TWRP screen area to the right (as indicated by the arrows) to start the backup. It will take awhile to create a nandroid of 6-8 GB.
(9) Make sure that you have a good nandroid backup created. If you want to be extra cautious, reboot into TWRP and restore the nandroid backup that you just created. TWRP should indicate if it was able to successfully restore the nandroid backup. Note that we are not going to use the TWRP restore function in this recovery process; we just want to make sure that the nandroid backup is good.
(10) TWRP will create an entire directory structure on the external SD card, top-level being "TWRP." Copy this entire directory stucture to a safe place on your PC.
(11) Now take a deep breath and, using the TWRP wipe function, wipe all partitions except EFS. TWRP has a screen showing all partitons to be wiped, with check marks beside all of them. Uncheck the EFS partition. That partition should not have been affected by BK Disabler and every write into EFS is somewhat risky. (Keeping in mind that restoring the nandroid backup or re-flashing to stock will both re-write the EFS partition; but those functions presumably know what they are doing.)
Also note: Wiping the /data partition by itself is equivalent to a factory data reset and should delete all of the BK Disabler Enterprise MDM/Kiosk-mode setup (as well as all of your non-system apps, data, settings, etc.) However, we are going to make sure that the phone is in completely factory stock pristine shape by re-flashing the stock ROM. Doing so will flash all partitions except /data, which we just wiped.
(12) Download the factory stock firmware from Sammobile that corresponds to your phone model, your version of Android and your carrier. It will download as a .zip file and will unzip to a file name reflecting your stock image and ending in _HOME.tar.md5. Don't change the file name or further decompress. Open Odin, press the "PDA" button and navigate to the _HOME.tar.md5 image. The other three file slots are left blank. Odin knows to extract all partitions from the image file in "PDA." By default, Odin is set to reboot the phone normally when the flash completes. Press the middle tab and uncheck that so that you can observe that the flashing operation terminated normally and completely. Do not select any other option. DO NOT select "repartition." Make sure that Odin recognizes your phone in the upper left box "ID:COM." Press "Start" and you will see the Odin log file populate on the Odin screen and you will see a flash progress bar on the phone. You will see a green "success" notification at the upper left of the Odin screen when the flashing operation completes successfully. Pull the battery to power the phone off and then re-insert battery.
(13) Next we will boot normally into the newly-flashed system. Before powering on, though, give this some thought. You will be faced with the "new phone" setup dialog and so should know your Google email address and password, name you want to use for the phone, etc. Also keep in mind that while you are fiddling with the setup, Google is busy getting your location, defaulting all of the settings to its best advantage, etc. And your carrier is busy downloading OTA Android and security updates to your phone. E.g., the big boys are infecting your phone as fast as they can and any controls that you previously set in place (e.g., via settings, freezing apps, firewall settings, etc.) to hold off the hoardes are no longer in place. It might be a good idea to put the phone into airplane mode immediately, pull the SIM card, turn off your wireless router, or whatever, to slow things down while you go through the new phone setup and adjust some of your settings. Just a thought...
(14) Now root your phone using your favorite rooting method. (This is necessary because the next (recovery) step uses the Titanium Backup app, which requires root.) For example, download Chainfire's SuperSu v2.82-SR5 zip file from here: https://download.chainfire.eu/1220/SuperSU/SR5-SuperSU-v2.82-SR5-20171001224502.zip Do not unzip. Move the SuperSu zip file to the internal or external SD card (to the top directory or any other directory is fine.) Use the Install function from within TWRP to navigate to the SuperSu zip file, highlight the zip file and swipe the TWRP action strip to install SuperSu. Now boot the phone normall (into the Android system) and you will be greeted by the SuperSu app. You may be given a choice whether to install SuperSu as "systemless" or to install it in the system partition. I prefer "systemless" because flashing a ROM (which overwrites the /system partition) does not wipe out root if SuperSu is installed as "systemless."
(15) Now download Titanium backup from the Play Store (paid Pro edition to be able to complete these steps). Also download and install any apps from which you need to recover data that are not system apps. (For example, if you use the stock messaging app, no need to download any other app to recover messages. However, if you use a non-stock messaging app, download and install that app now.)
(16) Now plug phone into PC USB and transfer the entire TWRP nandroid directory structure from whereever you copied it to on your PC to the internal SD card (Titanium will not recognize the nandroid file on the external SD card and will likely not recognize the nandroid file by itself without the TWRP directory structure).
(17) Now the amazing magical coordination between the TWRP team and the Titanium dev will become clear. Fire up Titanium and hit "Menu..." "Import/Export..." "Extract from Nandroid backup." Give Titanium awile to look into the Nandroid backup file and analyze it. When finished, Titanium will present all the apps and app data that it could find in a list for you to select from via checkmarks. Note that at the top of the screen you can select to restore apps only, data only, or apps + data. Also, the Titanium legend (font colors and icons) is quite extensive. You can study it under "Menu..." "Help/Licensing." Suffice it to say, though, the legend will indicate that few if any apps are available to restore. Why? Because, remember, the apps were hid away in a secure Knox container by the BK Disabler MDM app! So, logically TWRP was not able to include the apps in the nandroid backup. That's ok, because system apps were restored via re-flashing the stock ROM and you downloaded other apps that you needed to recover data for from the Play Store. I believe that its best just to choose "restore data" to avoid any problems with Titanium attempting to find apps in the nandroid when they don't exist there. However, if that is unsuccessful you could try restoring "apps + data." I would suggest restoring one app's data at a time. After each such restore, start up the app to make sure that its data is restored, then restore the next, etc.
(18) I was able to successfully recover all data, including contacts, calendar, SMS/MMS, phone log, K-9 email, etc. That said, going forward I will not go even one week without doing a full Titanium backup of all apps + data and less frequent TWRP nandroid backups, copying each to safe backup folders on my Windows PC. Of course, you could just enable Google Cloud sync. After all, why make Google work to get your data, why not just hand it to them?!
(19) Also, I am not too bitter about the Kunkunsoft BK Disabler for Samsung time-wasting experience. I did it to avoid burning time with the whole "rooting" scenario. But in the end I wasted much more time than would have been the case by just "doing it right" with TWRP and Titanium in the first place. I might even consider using Kunkunsoft's new whack-a-mole Play Store pop-up "Service Disabler," because Titanium does not freeze an app's individual services. But I would only do that if I can confirm that Service Disabler does not come anywhere near the "Samsung Knox Enterprise MDM/Kiosk Mode" area. What a nightmare!!
Update... I just read on a Kunkunsoft blog that his latest "no root" disabler "Package Disabler (All Android)" uses Google's Android SELinux "Device Owner" Enterprise Management "Device Policy Controller" functionality. This is the same old bad-boy unrecoverable "lock yourself out of your device" scenario as described above except even worse because it is probably even more secure than Knox and applies to all SELinux Android on any device after Kit-kat 4.4 or so. Basically the app takes over your phone as though it were a company-owned and managed phone. I would not touch it with a ten-foot pole and suggest that you just root your phone to avoid problems. I plan to contact Kunkunsoft to ask how his root version, "Service Disabler" works. If it works via Package Manager, like Titanium, then I will use it to re-acquire the ability to disable individual services. Otherwise I will just live without that luxury.
Package disablers from a Vietnamese developer "Kunkunsoft" have popped up in the Play Store under various names as this poor (and clearly very bright) guy plays "whack-a-mole" with Google and Samsung. Neither company is happy about Kunkunsoft's "Swiss Army Knife" ability to efficiently disable individual services associated with system apps and to thus selectively limit telemetry while maintaining app functionality, especially without root. The routine is that a newly-named Kunkunsoft package disabler appears in the Play Store, sometimes with a plugin listed with a covert developer name that is not Kunkunsoft, becomes popular, and the developer is harrassed by the big guns until they finally force him to modify his app/plugin to delete the capability of disabling individual services and/or they take his app down. Its a sad situation.
The last no-root incarnation of the Kunkunsoft app ("BK Disabler for Samsung" with "BK Plugin v2") disappeared about 6 weeks or so ago. It is now replaced by "Service Disabler" which requires root. I am writing this "how-to" mainly for any users of BK Disabler for Samsung (no root) who may disable some boot-critical system package or service like I did and be stuck with the spectre of data and cofiguration loss. I spent way too much time trying to figure out how Kunkunksoft disables packages and services without root, in order to try to recover my phone by undoing his magic from a custom recovery. To his credit the dev responded to my email for assistance. However, he merely insisted that I would need to factory reset and lose my data and would provide no clue about how his app operates.
After much trial and tribulation I figured out how the app works and why it cannot be undone. BK Disabler implements its services control magic without root by skillfully exploiting a subset of Samsung's home-grown security system, Knox. Specifically, the app operates as a Samsung Enterprise Mobile Device Management ("MDM") manager. Normally an MDM manager sits on a corporate server and allows IT personnnel to create and distribute device policies to Samsung phones. But BK Disabler is an Android app that is also an MDM manager, both running on the phone and controlling the phone! Pretty clever, huh? More specifically, BK Disabler creates a protected Knox MDM container, turns on Kiosk-mode in the phone, and allows only apps/services that have not been disabled to run in that Kiosk environment! This is all done in real time, so the user is unaware that every time he/she disables or re-enables an app or service, BK Disabler actually goes into MDM management mode and modifies the Knox Kiosk mode container! As you can see, the dev is very clever and engages in substantial recursive thinking to pull this off! He also had to purchase a Knox MDM Management license from Samsung. That is why the app is called "BK Disabler for Samsung." It only works on Samsung devices because Samsung, in an effort to capture the corporate market, has placed this powerful control mechanism in the hands of the corporate world, giving corporations the power to implement controls that are otherwise unavailable without root. You can also see why it would likely be near-impossible to undo BK Disabler's freezes from a recovery environment. You would need to break into Ft. Knox... (I was actually surprised to find that I could read an SqLite database containing signed lists of the packages that I had disabled. I thought about editing the unencrypted database but finally gave up after realizing that it was a Knox MDM setup. The disabled system apps/services preventing boot were protected in a Knox container and boot would have failed before my edited database could have been read by BK Disabler, if at all.
With that way-too-lengthy background in place, this is the way to recover should you become too aggressive with BK Disabler for Samsung or any other package disabler for that matter:
Notes:
(a) I tested the method described only on my ancient Samsung Galaxy S5 running "Marshmallow" (Android 6.0.1). The BK Disabler (Samsung) app will only install on Samsung models which include the older Samsung Knox security system and Enterprise MDM included in the stock ROMs. That said, this recovery procedure is generalized to recover data from any phone that is flashable using Odin, which can accept a flash a version of TWRP applicable to the phone and which can be rooted.
(b) Its a good idea to have the back cover of the phone loose because you will need to pull the battery during this procedure. If you have a phone without a removable battery, I'm not sure how you can turn the phone off following an Odin flash, as I have no experience with a phone without a removable battery. Turning the phone off after flashing TWRP is necessary to prevent TWRP from being removed by an automatic boot to the OS after the TWRP flash. The first boot following a TWRP flash must be to recovery and not to system in order to make TWRP "stick."
(1) Note that flashing TWRP in this step will set the warranty bit on Samsung phones, which allegedly voids the Samsung warranty. Whether or not doing so actually legally voids the warranty varies according to consumer protection and contract laws of various jurisdictions. Boot into download mode (hold volume down and home button while pressing power button.) Using Odin (I used v3.13.1), flash TWRP 3.2.1-0 KLTE. Make sure that Odin recognizes your phone. It will show up in the upper-left window "ID:COM." Press the middle tab and unselect "automatic reboot." The reason is that your initial boot following the flash must be into recovery; otherwise TWRP will be deleted by the normal system boot process. TWRP fixes this problem when you first boot into TWRP recovery. Press the "PDA" button and navigate to the TWRP flash file. After the TWRP flash loads into Odin ("ready"), press start. You will see a message in the upper left window that the flash completed successfully. Pull the battery to turn the phone off. Re-insert battery.
(2) Boot into recovery (hold volume up and the home button while pressing the power button); you will see the TWRP recovery screen. TWRP recovery is a work of art!
(3) TWRP recovery will mount both the internal and external SD cards as MTP devices, allowing you to see all of your user folders and files on both SD cards in Windows Explorer.
Note: FYI for noobs, the "internal SD card" is a portion of internal flash memory within the Android Linux /data partition that is allocated for user storage. The "external SD card" is an actual microSD card plugged into the slot above the SIM card and just above the top edge of the battery. Generally speaking, when Android refers to "SD card" it is referring to the internal SD card and not to a microSD card that you plug into the phone above the battery.
(4) In Windows Explorer, copy and paste all folders from both internal and external SD cards to a safe place on your desktop PC, laptop, etc. Note that you do not even need TWRP to perform this operation for the external SD card because you can take the microSD card out of the phone and transfer the files from an external microSD card reader.
(5) Now we will create a nandroid backup of the entire system, all Android Linux partitions. The reason that we copied the SD card data using Windows Explorer is that a TWRP nandroid backup does NOT include either internal or external SD card data. All bits of all other partitions are included in the TWRP nandroid backup. The TWRP folks consider us to be smart enough to copy our photos, videos documents, etc. from both internal and external SD cards using Windows Explorer. However that still leaves lots of our data, like our contacts, calendars, text messages, emails, phone call logs, etc. buried in the nandroid backup.
(6) In TWRP, select the external SD card as the backup destination (if you don't have an external SD card, go buy one before doing anything else. Format it to fat32 in a USB card reader plugged into a Windows system (separate from the phone). Then insert the microSD card into the phone above the SIM card.
(7) In TWRP, select all partitions to back up, with the external SD card selected as the destination to write the nandroid backup to.
(8) Swipe the indicated TWRP screen area to the right (as indicated by the arrows) to start the backup. It will take awhile to create a nandroid of 6-8 GB.
(9) Make sure that you have a good nandroid backup created. If you want to be extra cautious, reboot into TWRP and restore the nandroid backup that you just created. TWRP should indicate if it was able to successfully restore the nandroid backup. Note that we are not going to use the TWRP restore function in this recovery process; we just want to make sure that the nandroid backup is good.
(10) TWRP will create an entire directory structure on the external SD card, top-level being "TWRP." Copy this entire directory stucture to a safe place on your PC.
(11) Now take a deep breath and, using the TWRP wipe function, wipe all partitions except EFS. TWRP has a screen showing all partitons to be wiped, with check marks beside all of them. Uncheck the EFS partition. That partition should not have been affected by BK Disabler and every write into EFS is somewhat risky. (Keeping in mind that restoring the nandroid backup or re-flashing to stock will both re-write the EFS partition; but those functions presumably know what they are doing.)
Also note: Wiping the /data partition by itself is equivalent to a factory data reset and should delete all of the BK Disabler Enterprise MDM/Kiosk-mode setup (as well as all of your non-system apps, data, settings, etc.) However, we are going to make sure that the phone is in completely factory stock pristine shape by re-flashing the stock ROM. Doing so will flash all partitions except /data, which we just wiped.
(12) Download the factory stock firmware from Sammobile that corresponds to your phone model, your version of Android and your carrier. It will download as a .zip file and will unzip to a file name reflecting your stock image and ending in _HOME.tar.md5. Don't change the file name or further decompress. Open Odin, press the "PDA" button and navigate to the _HOME.tar.md5 image. The other three file slots are left blank. Odin knows to extract all partitions from the image file in "PDA." By default, Odin is set to reboot the phone normally when the flash completes. Press the middle tab and uncheck that so that you can observe that the flashing operation terminated normally and completely. Do not select any other option. DO NOT select "repartition." Make sure that Odin recognizes your phone in the upper left box "ID:COM." Press "Start" and you will see the Odin log file populate on the Odin screen and you will see a flash progress bar on the phone. You will see a green "success" notification at the upper left of the Odin screen when the flashing operation completes successfully. Pull the battery to power the phone off and then re-insert battery.
(13) Next we will boot normally into the newly-flashed system. Before powering on, though, give this some thought. You will be faced with the "new phone" setup dialog and so should know your Google email address and password, name you want to use for the phone, etc. Also keep in mind that while you are fiddling with the setup, Google is busy getting your location, defaulting all of the settings to its best advantage, etc. And your carrier is busy downloading OTA Android and security updates to your phone. E.g., the big boys are infecting your phone as fast as they can and any controls that you previously set in place (e.g., via settings, freezing apps, firewall settings, etc.) to hold off the hoardes are no longer in place. It might be a good idea to put the phone into airplane mode immediately, pull the SIM card, turn off your wireless router, or whatever, to slow things down while you go through the new phone setup and adjust some of your settings. Just a thought...
(14) Now root your phone using your favorite rooting method. (This is necessary because the next (recovery) step uses the Titanium Backup app, which requires root.) For example, download Chainfire's SuperSu v2.82-SR5 zip file from here: https://download.chainfire.eu/1220/SuperSU/SR5-SuperSU-v2.82-SR5-20171001224502.zip Do not unzip. Move the SuperSu zip file to the internal or external SD card (to the top directory or any other directory is fine.) Use the Install function from within TWRP to navigate to the SuperSu zip file, highlight the zip file and swipe the TWRP action strip to install SuperSu. Now boot the phone normall (into the Android system) and you will be greeted by the SuperSu app. You may be given a choice whether to install SuperSu as "systemless" or to install it in the system partition. I prefer "systemless" because flashing a ROM (which overwrites the /system partition) does not wipe out root if SuperSu is installed as "systemless."
(15) Now download Titanium backup from the Play Store (paid Pro edition to be able to complete these steps). Also download and install any apps from which you need to recover data that are not system apps. (For example, if you use the stock messaging app, no need to download any other app to recover messages. However, if you use a non-stock messaging app, download and install that app now.)
(16) Now plug phone into PC USB and transfer the entire TWRP nandroid directory structure from whereever you copied it to on your PC to the internal SD card (Titanium will not recognize the nandroid file on the external SD card and will likely not recognize the nandroid file by itself without the TWRP directory structure).
(17) Now the amazing magical coordination between the TWRP team and the Titanium dev will become clear. Fire up Titanium and hit "Menu..." "Import/Export..." "Extract from Nandroid backup." Give Titanium awile to look into the Nandroid backup file and analyze it. When finished, Titanium will present all the apps and app data that it could find in a list for you to select from via checkmarks. Note that at the top of the screen you can select to restore apps only, data only, or apps + data. Also, the Titanium legend (font colors and icons) is quite extensive. You can study it under "Menu..." "Help/Licensing." Suffice it to say, though, the legend will indicate that few if any apps are available to restore. Why? Because, remember, the apps were hid away in a secure Knox container by the BK Disabler MDM app! So, logically TWRP was not able to include the apps in the nandroid backup. That's ok, because system apps were restored via re-flashing the stock ROM and you downloaded other apps that you needed to recover data for from the Play Store. I believe that its best just to choose "restore data" to avoid any problems with Titanium attempting to find apps in the nandroid when they don't exist there. However, if that is unsuccessful you could try restoring "apps + data." I would suggest restoring one app's data at a time. After each such restore, start up the app to make sure that its data is restored, then restore the next, etc.
(18) I was able to successfully recover all data, including contacts, calendar, SMS/MMS, phone log, K-9 email, etc. That said, going forward I will not go even one week without doing a full Titanium backup of all apps + data and less frequent TWRP nandroid backups, copying each to safe backup folders on my Windows PC. Of course, you could just enable Google Cloud sync. After all, why make Google work to get your data, why not just hand it to them?!
(19) Also, I am not too bitter about the Kunkunsoft BK Disabler for Samsung time-wasting experience. I did it to avoid burning time with the whole "rooting" scenario. But in the end I wasted much more time than would have been the case by just "doing it right" with TWRP and Titanium in the first place. I might even consider using Kunkunsoft's new whack-a-mole Play Store pop-up "Service Disabler," because Titanium does not freeze an app's individual services. But I would only do that if I can confirm that Service Disabler does not come anywhere near the "Samsung Knox Enterprise MDM/Kiosk Mode" area. What a nightmare!!
Update... I just read on a Kunkunsoft blog that his latest "no root" disabler "Package Disabler (All Android)" uses Google's Android SELinux "Device Owner" Enterprise Management "Device Policy Controller" functionality. This is the same old bad-boy unrecoverable "lock yourself out of your device" scenario as described above except even worse because it is probably even more secure than Knox and applies to all SELinux Android on any device after Kit-kat 4.4 or so. Basically the app takes over your phone as though it were a company-owned and managed phone. I would not touch it with a ten-foot pole and suggest that you just root your phone to avoid problems. I plan to contact Kunkunsoft to ask how his root version, "Service Disabler" works. If it works via Package Manager, like Titanium, then I will use it to re-acquire the ability to disable individual services. Otherwise I will just live without that luxury.
Last edited:
