Teclast P98 4G ( A8H8 )

[yuv]

From nearly bricked to back to life.

That's in a nutshell tonight's experience. Buoyed by the unrelated good news I received today that I passed the lawyer licensing exams, I decided to boldly go where I have not been before.

I figured out how to use SP Flash Tools in Linux (I have even tried to write a tutorial into a new Topic, but somehow after pressing the the Post button it disappeared). And I tried to replicate yesterday's root results. I was not able to replicate and I found that my documentation was... sloppy.

First, right at the beginning, before adb push supersu /tmp, I forgot that I did the following:

adb shell
mount -o rw,remount /system
mount -o rw,remount /system /system
mount -o rw,remount /
mount -o rw,remount / /
exit

I left the block much later in the documentation.

Second, the two toolbox_mount commands wreck havoc. I skipped them and forgot to document it.

But then, even with those two corrections, I saw some errors I do not recall seeing yesterday and I was not able to root. My best guess at the moment is that I was in some sort of lucky situation that one of my previous, undocumented attempts with some of the PC apps has interacted with my current, not so well documented attempt at manually reproducing the work of the SuperSU installer, resulting in an incredible lucky moment that I can't repeat since I factory reset.

When I tried a third time, the tablet froze, hanging with the boot animation. At that point, nothing helped but flashing, and flashing I did.

• First, I flashed my earlier dd-made backups. They worked.
• Then I became bold, and flashed the modifications to my boot.img and system.img by hocuspocus69. The tablet froze before the boot animation and all I could do was get into Recovery Mode. Wiping the cache did not help. I had to reflash.
• So I tried the original stock lollipop from the XDA link in this thread, and it worked, with exact same result as my own backup.

Bottom line: I am back to square zero, but with the new found power of flashing.

Do I really need root to port CyanogenMod? reading the porting guide I have the impression that I have all the tools I need?

Anyway, long weekend ahead here. Not sure how much time I will get to spend tinkering with the tablet, but I have only four weeks left to finish turning it into something useful.

Any help/hint is, as always, appreciated.
Yuv

[hocuspocus69]

What a nightmare yuv ...have you try my boot.IMG + stock system? Just to have some clue!

[yuv]

What a nightmare yuv ...have you try my boot.IMG + stock system? Just to have some clue!

I have tried them only together (boot.L.img and system.L.img) after the best thing that comes near to a total reset (flashing my dd-made backup and clearing the cache and user data in recovery).

Does my account sound so nightmarish? The only thing I have seemingly lost is the tutorial I tried to write on this forum. My first, and probably my last. I will find some other outlet for my writings.

[hocuspocus69]

yuv Sorry for my bad use of english

[yuv]

After a long while off for reasons directly related to the P98-4G that I am not yet comfortable disclosing, some progress and some frustration to report. I'll write little chunks in logically separated bits. I'll start with the one effort that still eludes me: the build from source.

My long term goal is still a CyanogenMod 12.1 port. This requires a good understanding of the Android/CyanogenMod build system and three crucial elements:

• A device directory with the configuration settings for the particular device
• A vendor directory with the proprietary binary "blobs"
• A kernel directory which can contain either an extracted kernel or one built from source (preferred)

I gained sufficient understanding of the CyanogenMod build system in a couple of nights. I built ROMS from source for our family's Nexus 5, 6, and the latest addition, a Nexus 9. The Nexus 9 replaces the P98-4G in its original purpose: a birthday present that must be ready by the end of the month. I assumed that two months would have been sufficient to prepare the P98-4G and I was too optimistic. It took me only a few minutes to prepare the Nexus 9:

cd ~/android/system
repo sync -j 8
source build/envsetup.sh
breakfast flounder
croot
cd device/htc/flounder
./extract-files.sh
croot
brunch flounder

Let the PC churn for a little while and there comes a freshly baked cake ready to eat.

This leave the P98-4G as a redundant toy for me to reverse engineer in my spare time. Maybe one day it will be as easy to prepare a ROM from source for MTK devices, or maybe manufacturers are smarter and move to SoC from corporations that are more respectful of the spirit of the GPL.

Back to MTK-Hell, I found what I believe is a complete set of Mediatek kernel source code for recent SoC on Github and I was able to build it, but it is for a different MTK device. Next I need to understand from the bloatrom currently installed what configuration I need to build the kernel for the P98-4G. The proof will be in the pudding, i.e. substituting the built kernel in a recovery image and see if it boots. If it boots, the next step is to substitute the built kernel in a boot image and see if the system comes up and what hardware functionality is available. I have a plan!

Time to boot bloatrom P98-4G and see what I can find.

[yuv]

Flashing in Linux with Smart Phone Flash Tools (SPFT) is a breeze once the couple of pitfalls are known. Really. I got frustrated when I tutorial I wrote to a new thread on this forum disappeared with no trace, so I will just give the jist:

• Download location: http://mtk2000.ucoz.ru/
• Prepare for first use

sudo apt-get install unrar libusb-dev
mkdir ~/bin/
cd ~/bin/
mv ~/Downloads/SP_Flash_Tool_Linux_v5.1524.00.100.rar .
unrar x SP_Flash_Tool_Linux_v5.1524.00.100.rar
rm SP_Flash_Tool_Linux_v5.1524.00.100.rar
mv SP_F* SPFT
cd SPFT
chmod u+x flash_tool.sh
chmod u+x flash_tool

• Connect the device to identify its ID. Repeat with USB debugging on and off; and repeat also in Factory Mode and in Recovery Mode (a total of four times) because the device can announce itself with four different IDs.

lsusb

• Grant unprivileged user access to the device

echo "SUBSYSTEM==\"usb\", ATTRS{idVendor}==\"0e8d\", MODE=\"0666\"" | sudo tee -a /etc/udev/rules.d/51-android.rules
echo "SUBSYSTEM==\"usb\", ATTRS{idVendor}==\"0bb4\", MODE=\"0666\"" | sudo tee -a /etc/udev/rules.d/51-android.rules

• Start SPFT

sudo apt-get remove modemmanager
lsmod | grep cdc_acm
modprobe cdc_acm
~/bin/SPFT/flash_tool.sh

• Load a scatter file
• Select the options and files to flash. Make sure you know what you are doing, you could brick your device at this point and it is solely your responsibility. This quick jist does not tell you what to do, just how to do it.
• Turn the device off (or press the reset button with a pin)
• Click on the Download button in SPFT
• Connect the device and watch things happen
• After flashing, restore the system

sudo apt-get install modemmanager

Pitfalls:

• dependency on libusb-dev. <RANT>Whoever publishes the software should have used .deb or .rpm instead of .rar for packaging it properly. Then installation of libusb-dev would have happened automatically on installation of SPFT.</RANT>
• incompatibilty with modemmanager. Recent versions of Ubuntu ship with modemmanager installed by default, and modemmanager is incompatible with SPFT. I have not researched this one in detail.

Next, let's do some flashing.

[yuv]

I can confirm that the ROM on my P98-4G, that I have extracted with dd, is exactly the same a the ROM linked in message #24. However I cannot simply mount its system partition like I could mount mine with

mkdir -p /tmp/system
sudo mount -o loop system.img /tmp/system/

.

I also could not mount the system.L.img that hocuspocus69 derived from mine, I have not investigated further. In post #13 I had investigated the difference between his boot.L.img and the boot.img I extracted from my device, and I realized I missed some minor but important differences in init.rc:

--- boot/boot.img-ramdisk/init.rc    2015-07-12 22:35:05.673075697 -0400
+++ hocuspocus/boot/boot.img-ramdisk/init.rc    2015-07-12 21:47:00.992397713 -0400
@@ -69,7 +69,7 @@ loglevel 6 ####
     # See storage config details at http://source.android.com/tech/storage/
     mkdir /mnt/shell 0700 shell shell
     mkdir /mnt/media_rw 0700 media_rw media_rw
-    mkdir /storage 0751 root sdcard_r
+    mkdir /storage 0751 root sdcard_rw
 
     # Directory for putting things only root should see.
     mkdir /mnt/secure 0700 root root
@@ -568,14 +568,14 @@ service drm /system/bin/drmserver
     class main
     user drm
     # group drm system inet drmrpc ####
-    group drm system inet drmrpc sdcard_r ####
+    group drm system inet drmrpc sdcard_rw ####
 
 service media /system/bin/mediaserver
     class main
     user root ####
 #   google default ####
 #   user media    ####
-    group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm media sdcard_r system net_bt_stack ####
+    group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm media sdcard_rw system net_bt_stack ####
 #   google default ####
 #   group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm ####
 
@@ -651,7 +651,6 @@ service pre-recovery /system/bin/uncrypt
     class main
     disabled
     oneshot
-
 #RileyROM add init.d support to boot/init.rc
 service runparts /system/bin/run-parts /system/etc/init.d
     class core
@@ -671,6 +670,7 @@ service daemonsu /system/xbin/su --daemo
     user root
     oneshot
 
+
 #RileyROM preinstall  add preinstall support to boot/init.rc
 service preinstall /system/bin/preinstall.sh
     class main

Moreover, when unpacking both with mtk-tools, the second offest value in boot.img-args.txt is 0x00f00000 (hocuspocus69) instead of 0x00e88000 (original). I used the latest version of mtk-tools and if I recall correctly HocusPocus used Carliv's Image Kitchen. I have the Linux version of Carliv's Image Kitchen, but I have not bothered yet to try to understand the difference. The same RANT about SPFT packging could be said of Carliv's Image Kitchen.

Instead, I went on a flashing party and on a cleaning party. The flashing party was uneventful. Anything I tried to flash failed. Different recoveries from MT6752 phones failed. I tried to mix hocuspocus69 boot.L.img with factory system but it hanged on the boot animation. The cleaning party, on the other hand... that was fun and more is coming. I will make a few more cleaning attempts and will post about it later.

[hocuspocus69]

yuv you are doing a great job...i'm discovered there is no lollipop update yet for t98! Follow your work but i'm windows side...good luck
Ps if i heard something ....

[yuv]

The cleaning party, a work in progress with some important successes

I started with a clean factory bloatrom. At first, I did light cleaning. I dragged and dropped on the trashcan every app I could. And yet when I browsed the file system with adb shell, some of them that I swear I deleted were still there.

Pitfall: Multiple Users! In the presence of multiple users, drag&dropping to uninstall only performs "uninstall" for the current user. It would be nicer to have a warning. To work around this, as device owner go to Settings > Apps, find the app, open the app's info. In the overflow menu (3 vertical dots), choose Uninstall for all users. <RANT>This is what I dislike about Lollipop: overengineered for too many clicks, why can't they put two trashcan icons for the drag&dropping process?</RANT>

Anyway, I decided that the launcher needed a complete facelift and installed Cyanogenmod's Trebuchet Launcher.

adb root
adb install L_Trebuchet_2015.04.04.apk

Before doing the next operations, I made sure it is selected as launcher, then...

adb shell
mount -o rw,remount /system
rm -fr /system/priv-app/JuiLauncher_EE56/
exit
adb reboot

No more eye sore! In Trebuchet I select Vertical layout mode for alpha sorting of apps in the drawer.

Emboldened by this little success, I went on to wipe every crapware I could find

adb root
adb remount
adb shell
cd /system/vendor/operator/app
rm CleanMaster.apk
rm JuiWallpaperLibrary.apk
rm KuwoPlayerV3_6.3.9.0_zhangku02_29FA.apk
rm PadaGameCenter.apk
rm PadaServiceFramework.apk
rm QYVideoClient_5.5_for_padPlayer_0421_3D6D.apk
rm ReadingJoyHD_v5.8.8.26_store_zhangku_6C32.apk
rm UserManual-3G-V3.02-20140808-68F3.apk
rm aimeituan-shenzhenleyu1-signed-aligned-041715_650E.apk
rm cn.keyshare.course.taidian_tai_dian-20150123_5909.apk
rm com.dianxinos.optimizer.channel_channel_1012389f_74E9.apk
rm iFlyIME_v5.0.1627.01010340_7960.apk
rm market.apk
rm ninegameclienthd.apk
rm taidiantianqiv2.3_20150206_1E01.apk
exit
adb reboot

Ideally one should reboot often to make sure that what is removed is not critical; and backup the system image at every step so that the last working one can be reflashed.

This one was big bloat, and it seems that the functionality that such a file(name) could provide is not available on this phablet:

adb root
adb remount
adb shell
rm /etc/iAmCdRom.iso

And then I bumped into a really tenacious stain:

cd /system/app
rm Superuser.apk

Yes, what is the point to keep KingRoot if it does not work? alas, this last command returned an OPERATION NOT PERMITTED error that got me scratching my head. After all, I have root user from the console. I can remove other apps with similar permission:

rm -fr LiveWallpapersPicker/

At first I suspected SELinux:

getenforce
setenforce Permissive
# alternative
setenforce 0

But that was not it.

So I backed up the partition with dd and mounted it locally to investigate and I found that somebody has been smart about protecting a file using extended attributes in ext4 systems:

mkdir -p /tmp/system
sudo mount -o loop system.img /tmp/system/
cd /tmp/system/app/
sudo lsattr Superuser.apk

Output:

-----a-A-----e-- Superuser.apk

From the chattr man page:

• The 'e' attribute indicates that the file is using extents for mapping the blocks on disk. It may not be removed using chattr(1)
• A file with the 'a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
• When a file with the 'A' attribute set is accessed, its atime record is not modified. This avoids a certain amount of disk I/O for laptop systems.

A smart way to protect a file against [accidental|intentional] overwriting, and pretty permanent on a system without the chattr binary. But on Linux I easily removed that attribute:

sudo chattr -a Superuser.apk
cd
sudo umount /tmp/system/

Then I fired up SPFT and flashed the filesystem back on the device. I was careful not to delete the file immediately. I deleted it back on the device and was happy to see the error message that KingRoot stopped working and that the cleaner device rebooted without any problem.

Next I installed F-droid, my favourite software source. Due to a bug with Lollipop 5.0 (that has already been fixed in the codebase), only an older version of F-droid can be installed on this craprom.

wget https://f-droid.org/archive/org.fdroid.fdroid_830.apk
adb install org.fdroid.fdroid_830.apk

This bug has been reported December 16, 2014, fixed by Google December 19, 2014 and yet more than half a year later a careless manufacturer keeps spreading broken software. How about fixing Stagefright, Teclast/Taipower? <RANT>Sellers, manufacturers, and suppliers (I am looking at you, Mediatek!) prefer to sell the next billion devices rather than fix the defective ones they have sold!</RANT>. Another argument in favour of Open Source, and another justification for the premium paid for Google Nexus devices. Google empowers users' self-support so that devices do not become obsolete before their time. No such bug (and no Stagefright) on our family's Nexus 5, 6, 9 running self-built CyanogenMod.

There is more cleaning to do before I can declare this device reasonably clean:

• /etc/security/otacerts.zip: deleting this one will prevent OTA updates, which I am fine with. I do not trust OTA updates from this source. I'll download, analyze, and ponder what to apply. Or better: by the time there is an "official" update, I will have already my own self-built and self-supported CyanogenMod running.
• /etc/security/cacerts: enough rants for today, so I will not talk about the broken way devices and browsers trust encrypted sites. Suffice it to say that you want to look hard at every single one of these certificates and make sure you really trust the entity to which it belongs. This is something one should also do on the PC, on the browser, etc.
• /etc/security/cacerts_supl: to be analyzed, same as above.

Let's not forget the primary reason for all of this Spring cleaning in late Summer: gathering of information for the kernel and device configuration. These files/directories may be interesting, either from their name or from their content:

• /system/etc/firmware/WIFI_RAM_CODE_6752
• /system/etc/mddb/
• /system/data/misc/ProjectConfig.mk
• /system/etc/recovery.fstab
• /system/etc/recovery.xml

Then there are files that may deserve deletion, or analysis to find what else can be deleted:

• /system/data/recovery_rootcheck
• /system/etc/install-recovery.sh
• /system/etc/install_recovery.sh
• /system/etc/recovery-resource.dat
• /system/etc/jui_workspace.xml

The work is not over, but the day (and the weekend) is. I welcome further input/research/sharing into these files.
Yuv

[yuv]

I just wrote a long post detailing the clean up. I hit the "Post Reply" button and it disappears. Just like my tutorial about flashing with Linux a few weeks ago. I have no backup. I am frustrated. If it does not appear in this thread, I will stop using this forum for any serious communication.

[yuv]

Rooted! Consistent and repeatable result starting from original ROM.
Busybox from my CyanogenMod 12.1 build for the Nexus 9 works like a charm too.
I still have some issues with repackaging system, and I am still trying to push it further with the removal of bloatware from the original BloatROM. I have also tried, unsuccessfully so far, to transplant CyanogenMod on top of the rooted ROM.

This is the list of applications that I am considering removing/replacing. Any hint regarding what cannot be removed is highly appreciated.

/system/vendor/operator/app: removed all with no regrets

• CleanMaster.apk
• JuiWallpaperLibrary.apk
• KuwoPlayerV3_6.3.9.0_zhangku02_29FA.apk
• PadaGameCenter.apk
• PadaServiceFramework.apk
• QYVideoClient_5.5_for_padPlayer_0421_3D6D.apk
• ReadingJoyHD_v5.8.8.26_store_zhangku_6C32.apk
• UserManual-3G-V3.02-20140808-68F3.apk
• aimeituan-shenzhenleyu1-signed-aligned-041715_650E.apk
• cn.keyshare.course.taidian_tai_dian-20150123_5909.apk
• com.dianxinos.optimizer.channel_channel_1012389f_7 4E9.apk
• iFlyIME_v5.0.1627.01010340_7960.apk
• market.apk
• ninegameclienthd.apk
• taidiantianqiv2.3_20150206_1E01.apk

/system/priv-app: tried removing all and replace them with the equivalent CM-12.1, but the system crashed badly and I had to reflash:

• BackupRestoreConfirmation
• CDS_INFO
• CalendarProvider
• Contacts
• ContactsProvider
• DefaultContainerService
• Dialer
• DownloadProvider
• ExternalStorageProvider
• FusedLocation
• GoogleFeedback
• GoogleLoginService
• GooglePartnerSetup
• GooglePlayServices
• GoogleServicesFramework
• GoolePlayStore
• HotKnotBeam
• HotKnotCommonUI
• InputDevices
• JuiLauncher_EE56 - must install alternative launcher before removing
• ManagedProvisioning
• MediaProvider
• Mms
• MmsService
• OneTimeInitializer
• ProxyHandler
• Settings
• SettingsProvider
• SharedStorageBackup
• Shell
• SystemUI
• TeleService
• Telecom
• TelephonyProvider
• VpnDialogs
• WallpaperCropper

/system/app : still undecided which one can be removed

• ApplicationsProvider
• AtciService
• AutoDialer
• AutoUpdate
• BSPTelephonyDevTool
• BasicDreams
• BatteryWarning
• Bluetooth
• Browser
• Calculator
• Calendar
• CalendarImporter
• CaptivePortalLogin
• CertInstaller
• DeskClock
• DocumentsUI
• DownloadProviderUi
• DrmProvider
• Email
• EngineerMode
• EngineerModeSim
• Exchange2
• FTPreCheck
• FWUpgradeProvider
• FileManager
• Galaxy4
• Gallery2
• HTMLViewer
• HoloSpiralWallpaper
• HotKnot
• KeyChain
• LatinIME
• LiveWallpapers
• LiveWallpapersPicker
• LocationEM2
• MTKAndroidSuiteDaemon
• MTKThermalManager
• MiraVision
• MtkBt
• MtkFloatMenu
• Music
• MusicFX
• NlpService
• NoiseField
• Omacp
• PacProcessor
• PackageInstaller
• PhaseBeam
• PhotoTable
• PicoTts
• PrintSpooler
• Provision
• QuickSearchBox
• SchedulePowerOnOff
• SoundRecorder
• Stk1
• UserDictionaryProvider
• VisualizationWallpapers
• VoiceCommand
• VoiceExtension
• VoiceUnlock
• YGPS
• webview

I still need to find a place where I can publish the details of what I did (I will not risk any important document on this post-globbing forum and for now I keep them on my local MediaWiki instance); and of course a place to package and distribute a ROM, what 99% of the lurkers are waiting for. The goal is a skinny ROM, the more is cut away, the better.

[hocuspocus69]

GREAT!!!!!!

[Matteuz]

Yuv great job !!

Why do not publish your work on XDA Dev?

[yuv]

Why do not publish your work

I am having doubts. I was able to root the device because of a stupid sloppy mistake of the Teclast chingeneers. If I publish my finding and they read them, they will fix their mistake and we can forget rooting future devices.

on XDA Dev?

IMHO XDA Dev is a very unhealthy place. It suffers of many of the same problems that freaktab.com suffers, compounded by the quantity of participants. Some of the problems are site/community-specific, others are common to all web-based forums. A common problem in my view is that important knowledge gets drowned by irrelevant posts. For publication of community-sourced knowledge I prefer a wiki, and for current chatter/conversation I prefer mailing lists. But neither a wiki nor a mailing list offer operators so many commercial opportunities as web-based forums, so they have no incentive to set up and operate those other tools and users are stuck in a forum for lack of choice.

Back to work. I have tried mixing my self-compiled kernel with a ram-disk to make a recovery and so far my attempts have failed. The number of configuration parameters is daunting. I keep poking around to understand with what configuration parameters the kernel in the ROM was built. Unfortunately, they did not leave behind a /proc/config.gz. If anybody has a Teclast device with a /proc/config.gz output, I'd be interested to see it.

[hocuspocus69]

How do you do self compiling kernel without source code? Thanx