Well, the time has come that I think my kernel is ready for public consumption.
THIS IS ONLY FOR THE USA VERSION OF THE GALAXY PLAYER 5.0 (YP-G70). If you have a mechanical home button instead of capacitive buttons at the bottom, do not flash this (rumirand has a kernel for you)! If you have a 4.0, do not flash this (SteveS has a kernel for you)!
Read the first three posts of this thread COMPLETELY before asking questions - if you ask a question that is answered in the first three posts, you WILL be flamed.
I'm continuing my Daily Driver name, even though it isn't as good of a name as it used to be. It is my daily driver - but what kernel dev doesn't use their own kernel as a daily driver? It made more sense in the Infuse days when I was running my own unreleased kernel for months and a few people asked for it. Oh well, I'm lazy - same name for now.
This is going to be maintained in the same manner and spirit as my other Daily Driver releases for the Samsung Infuse and Samsung SGH-I777 (AT&T Galaxy S II) - http://forum.xda-developers.com/showthread.php?t=1212795 and http://forum.xda-developers.com/showthread.php?t=1289460
It is built from sources at https://github.com/Entropy512/linux_kernel_galaxyplayer and initramfs at https://github.com/Entropy512/initramfs_yp-g70
Current features:
coolbho3k's Samsung Sleep of Death patch - allows stable use of screen-off profiles with limits below 800 MHz in SetCPU
netarchy's conservative governor tuning patch - Reduces the polling interval, allowing conservative to ramp up/down faster. Over in I9100 land they're calling this "lionheart" and it's all the rage. (It makes me sad when people won't accept a governor until it's renamed and hyped up way beyond what it is...) As an example, a GSII would take 0.4 seconds to ramp from 200 to 1200 MHz with the default conservative governor, it can go all the way in 0.1 second with this patch.
conservative set to default governor - use SetCPU or a similar app to change it
jhash3
TinyRCU
CIFS and Tunneling modules included
ext4 partition mounting support in kernel and initramfs thanks to rumirand - ghetto Lagfix baby!
CWM 5.0.2.7 based recovery - Mostly tested, seems working, but may have a few bugs still to work out, rumirand helped a lot on this one
Insecure kernel - gives you automatic root in ADB shells
Per-file fsync() disable capability - see "dangerous features" documentation below
Standard bootanimation (/system/media/bootanimation.zip) support
Charginghacks - faster charging at low battery, slightly slower near the end, overall faster charging while trying to minimize battery stress
CPU core voltage control - use SetCPU or a similar app
CPU overclock to 1.2 GHz - use SetCPU or a similar app
Planned features, short-term:
Pull a few other bugfix commits from my other kernels
Clean up CWM implementation
Planned features, mid-term:
Proper Voodoo Lagfix support (Automatic partition conversion instead of manual)
Planned features, long-term:
Overclock beyond 1.2 if people prove they can handle 1.2 with maturity (Infuse community couldn't handle any OC in a responsible manner...)
Features not planned:
Anything that has a high risk of trading off stability for performance, unless it can be completely disabled by default
Alternative governors - They almost always cause wacky behavior in some cases, and they don't offer anything that can't be done with a combo of SetCPU profiles and tuning the conservative governor now that the minimum poll rate has been dropped.
How to flash .tar releases:
Linux/MacOS:
I forgot that Heimdall doesn't like this particular device - you will need to use a Windows virtual machine with USB passthrough support (like VirtualBox) and Odin, or root the device using the zergRush exploit and follow the "rooted device" instructions. (Ambrice has a fixed version of heimdall, but it must be compiled from source. If you know how to do that you don't need tips on how to use it. )
Windows:
Enter download mode - Power off your device completely, hold VolDn, and insert the USB cable
Use Odin - Google it or search these forums for details - try AdamOutler's resurrector thread in this Development forum
Any rooted device:
Extract the zImage from the .tar file of the release. On Linux, it can be the following (which should work in an ADB or Terminal Emulator shell on the Player itself.)
Code:
tar xvf <releasefile>.tar
From a shell with root access (ADB or Terminal Emulator), do the following:
Code:
dd if=zImage of=/dev/block/mmcblk0p11
How to flash .zip releases:
Put it on your sdcard, enter CWM, flash the .zip using CWM
If you do not have CWM, install an older .tar release then flash, or follow the "Any rooted device" instructions above, but extract the zImage from the .zip instead of a .tar
3/5/2012 Release:
Overclocking to 1.2 GHz (use SetCPU or a similar app to enable)
Support for running scripts in /system/etc/init.d
3/3/2012 Release:
Voltage control (no overclock yet, coming next)
1/29/2012 Release:
charginghacks from Infuse: Charging current on a wall adapter raised to 800 mA at lower battery, dropping to 700, then 600 (stock), then 550 (slightly below stock) as battery voltage reaches maximum. This gives overall lower charge times while trying to not stress the battery too much.
Also, final charge termination happens earlier - while this results in slightly less battery capacity per charge, it will help the battery retain capacity over time.
1/23/2012 Release:
Initramfs: Standard bootanimation support. Place a standard bootanimation in /system/media/bootanimation.zip - Note: The "stock" bootup sound still plays.
1/22/2012 Release:
A few bugfixes and power management improvements pulled in from other kernels
Ability to disable per-file fsync() - good for benchmark epeen, potentially dangerous for your data
1/14/2011 Release:
Initial release
FAQ
Q: Why does CWM default to my external SD card for backup/restore/flashing ZIPs?
A: This is the standard for Android devices going forward - internal on /emmc and external on /sdcard
Q: How do I enter CWM?
A: Until ROMs come out that have extended power menu mods: Power off your device, then:
Hold VolUp
Hold Power
Release Power when the SAMSUNG screen appears (continue holding VolUp)
Release VolUp when CWM appears
Q: I'm still not rooted?
As stated in the features, an insecure kernel only provides root in an ADB shell. Either use ADB to push /system/bin/su and /system/app/Superuser.apk and chmod them to the correct permissions, or take the easy way out and flash ChainsDD's Superuser package in CWM - http://androidsu.com/superuser/
Q: I used ROM Manager to do something, and something weird happened/went wrong. Why?
A: ROM Manager has not worked properly on any device I have ever owned. It softbricked any Infuse that had Voodoo Lagfix enabled, and never works properly on the SGH-I777. The only thing I've ever seen it do right was install gapps on CM7 on the I777.
Q: My battery will never charge past 80%, why?
A: The way Samsung estimates state of charge on our devices is extremely primitive and, in general, poor. Instead of a dedicated fuel gauge IC, they have tried to estimate battery directly from voltage with some funky compensation offsets depending on current operating state - the offset for wall charging is so high that it is impossible for the battery to read higher than 80% when on a wall charger unless you're putting the device under heavy load to activate some of the other compensation offsets. Sometimes it seems like the compensation code doesn't "kick in" when plugging in a charger, allowing you to see a higher number, other times it'll get "stuck on" even after removing the charger. The general thing, though, is that any percentage estimates of battery state are WILDLY inaccurate.
Q: Can you implement Voodoo Sound?
A: No - We have the same audio chip as the Galaxy S2 and Galaxy Note (Yamaha MC1N2) - Voodoo Sound requires a Wolfson WM8994.
Documentation on "dangerous" features:
Per-File fsync() disable:
This allows you to disable per-file write forced syncs. (e.g. if an app tries to force a write straight to disk, it'll just go to cache). This achieves the same goal as the modded sqlite hacks seen in tweaks such as USAS, however it can be disabled at runtime.
WARNING: THIS CAN CAUSE DATA LOSS OR CORRUPTION IN A CRASH
To enable, do the following in a terminal, or add it to an init.d script (look at my ondemand script as an example):
Code:
echo "1" > /sys/module/sync/parameters/fsync_disabled
And to disable (return to the default):
Code:
echo "0" > /sys/module/sync/parameters/fsync_disabled
Good for around 200 points of epeen in the database benchmarks in Antutu or 500-600 points of epeen in Quadrant. Real-world benefit: Probably not worth the data integrity risk, but you've got a choice now.
*reserved for whatever the heck I forgot above*
Thanks a ton Entropy512!! Been waiting for this.
Going to have to buy you a six pack via the Donate button!
Congrats Entropy512. I'm really thankful for your cooperation.
Its finally here!! Thanks so much entropy
Nice job entropy! Good to see that there is at least some development going on for these devices. This makes me wish I got a 5.0 instead..but I'm stuck with a 4.0.
Sent from my YP-G1 using Tapatalk
Thank You
I myself along with others appreciate you developing for the Galaxy Player 5.0 it is a great music player and it falls in the Galaxy family its a good device
Sent from my Galaxy Nexus using Xparent Blue Tapatalk
Says we can use Odin...do see put this in a phone or pda slot
Zei said:
Says we can use Odin...do see put this in a phone or pda slot
Click to expand...
Click to collapse
PDA - only modems go in phone I believe.
Just like flashing any other kernel in Odin.
Edit: CRAP I have Heimdall instructions but Heimdall won't work on the Player... I'm so habitually used to Heimdalling...
Would a factory stock image + root + this be good enough to post if done w/ the backup/restore feature?
Zei said:
Says we can use Odin...do see put this in a phone or pda slot
Click to expand...
Click to collapse
Yes when you use odin you will need to put the rom in PDA slot.If yiu use heimdall you will need to extract and flash the files separatly.
I hope this helps.
---------- Post added at 11:53 AM ---------- Previous post was at 11:53 AM ----------
Entropy512 said:
PDA - only modems go in phone I believe.
Just like flashing any other kernel in Odin.
Edit: CRAP I have Heimdall instructions but Heimdall won't work on the Player... I'm so habitually used to Heimdalling...
Click to expand...
Click to collapse
Heimdall does work on the player. I use it.
Hmm... odd, I tried to use it and it gave me some odd errors I've never seen before (I forget what at the moment) and then put me into forced download mode. I know a pit-dump has some rather odd looking results. Maybe if I just try and flash a kernel it will work.
I'll try again later today, and edit the instructions if it works.
I have my Player shut off for most of today - I've been having strange battery drain problems on my GSII for the past week or so, only when at home - and it seems like it started when I got the Player. So I'm shutting it off to see if it actually is affecting my phone.
Edit: Heimdall still isn't working for me
Code:
Heimdall v1.3.1, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...
Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
Handshaking with Loke...
Beginning session...
Session begun with device of type: 0
Downloading device's PIT file...
PIT file download sucessful
Uploading KERNEL
100%
ERROR: Failed to confirm end of file transfer sequence!
KERNEL upload failed!
Ending session...
Rebooting device...
Re-attaching kernel driver...
After I flashed your kernel it won't let me connect to the market, my Wi-Fi is turned on and I connect to the browser just fine but not the market, help?
That's strange - no problems with market connections here. (Edit: Just updated BetterBatteryStats...)
Try rebooting?
Or wait a bit - sometimes the Market just goes down.
Entropy512, I've been studying your github and how you enable ext4 support in the kernel. Could you explain how you did it? I know it has to do with editing "/ arch / arm / configs / yp_g70_usa_defconfig" but I can't find that file in samsung's source or on Steve'S github. And after you do that you just edit the mount points in init.rc, right? I'm asking because I'm gonna try to get ext4 (lagifx) for my 4.0!
Thanks.
P.S. sorry if I'm a noob
klin1344 said:
Entropy512, I've been studying your github and how you enable ext4 support in the kernel. Could you explain how you did it? I know it has to do with editing "/ arch / arm / configs / yp_g70_usa_defconfig" but I can't find that file in samsung's source or on Steve'S github. And after you do that you just edit the mount points in init.rc, right? I'm asking because I'm gonna try to get ext4 (lagifx) for my 4.0!
Thanks.
P.S. sorry if I'm a noob
Click to expand...
Click to collapse
yp_g70_usa_defconfig was copied from venturi_usa_defconfig prior to modifying it - I decided to start maintaining my own defconfig rather than overwriting the original one.
Galaxy Player 4.0 is palladio instead of venturi. SteveS also uses a renamed defconfig though - something like steves_blahblahblah_defconfig
To change things for a 4.0, it would be something like
Code:
make steves_blahblahblahwhateverthisis_defconfig
make menuconfig (enable ext4 support in the menus here)
cp .config arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git add arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git commit
Entropy512 said:
yp_g70_usa_defconfig was copied from venturi_usa_defconfig prior to modifying it - I decided to start maintaining my own defconfig rather than overwriting the original one.
Galaxy Player 4.0 is palladio instead of venturi. SteveS also uses a renamed defconfig though - something like steves_blahblahblah_defconfig
To change things for a 4.0, it would be something like
Code:
make steves_blahblahblahwhateverthisis_defconfig
make menuconfig (enable ext4 support in the menus here)
cp .config arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git add arch/arm/configs/steves_blahblahblahwhateverthisis_defconfig
git commit
Click to expand...
Click to collapse
Cool thanks! Will definitely try it out.
Hi, I've got a Xperia Neo V with locked bootloader, I had Gingerbread (compilation 0.42) but yesterday, I decided to install the oficial ICS update. I had installed Setcpu with these values: min245Mhz, max1024Mhz (governor: ondemand) , I updated to ICS and I noticed it was very slow, then I downloaded "Antutu cpu master", and the values were the same I used to use in GB, so I installed Gingerbread again, rooted it, installed setcpu and set these speeds, min1024Mhz, max1024Mhz (governor: performance) and that way I should have those values in ICS, but the problem is when I restart the phone, those values dissapear, and set 245,1024 and governor ondemand. When I select "Set on boot", it still being slow. I updated from GB to ICS (and vice versa) but there is no way to change those values (245,1024) and the governor(ondemand). Is there any way to modify cpu speed? For example modifying a specific configuration file without using setcpu or any other app?
I hope you understand me, and help if you can
Thanks!
Maybe a problem with the stock kernel.
You can try using terminal emulator if you can install the proper scripts.
But acc. to me it needs unlocked bootloader.
Sent from my MT11i
criscracker said:
For example modifying a specific configuration file without using setcpu or any other app?
[/COLOR]
I hope you understand me, and help if you can
Thanks!
Click to expand...
Click to collapse
You could write a script to be run at boot (init.d) that changes CPU speed, however (this might be an obvious question) which kernel are you running??, because AFAIK Sony stock kernel doesn't allow OC/UV, meaning that no matter what you do you won't be able to change CPU speed or governor.
Lenovo Tab 3 8/TB3-850F
Question & Answer Forum
Link & General Resource Guide
RE: Stock & Custom ROM(s)
INTRODUCTION & PURPOSE:
I have started this thread as a Q&A forum and general info guide for my Stock 6.0 ROM for the Lenovo Tab 3 8, and as a forum for my stock-based custom ROM which is nearing completion. In addition, I have posted some useful threads for this device below. It has been brought to my attention by XDA Senior Member @pndwal, as well as other members, that topics regarding systemless rooting, dm-verity, force encryption, Trusted Execution Environment (/tee1 & /tee2), etc., need a dedicated forum for open discussion and brain-storming, all while adhering to XDA's policy of staying on topic in the device threads. In addition to the topics outlined, this forum welcomes any questions, concerns and colloquy regarding ROMs, kernels, recoveries, & other development for this device.
LENOVO TAB 3 8/TB3-850F LINKS:
Stock Android 6.0 ROM Thread: https://forum.xda-developers.com/android/general/rom-lenovo-tab-3-8-tb3-850f-t3617594
Bootloader, TWRP & Rooting: https://forum.xda-developers.com/android/general/guide-lenovo-tab3-8-tb3-850f-t3559786/page17
Unbricking/Restoration Tutorial: https://forum.xda-developers.com/android/help/lenovo-tab-3-8-tb3-850f-unbrick-root-t3598727
Stock Firmware Partition Images: https://forum.xda-developers.com/android/general/rom-lenovo-tab-3-8-tb3-850f-android-6-0-t3593043
Lenovo Tab 3 8" User Manual (PDF)
for TB3-850F & TB3-850M: English: https://drive.google.com/file/d/18gCTfuZecJnlB0ddBIN02YPaDpuvmzov/view?usp=drivesdk
Lenovo File Manager (APK): https://forum.xda-developers.com/android/general/app-lenovo-file-manager-lenovo-tab-3-8-t3706161
RULES:
Rule 1: Be respectful to XDA policies and to one another. We are all here to learn and to grow. The only stupid question is a question not asked;
Rule 2: Read Rule 1.
MotoJunkie01 said:
It has been brought to my attention by XDA Senior Member @pndwal, as well as other members, that topics regarding systemless rooting, dm-verity, force encryption, Trusted Execution Environment (/tee1 & /tee2), etc., need a dedicated forum for open discussion and brain-storming, all while adhering to XDA's policy of staying on topic in the device threads.
Click to expand...
Click to collapse
MotoJunkie01 said:
@pndwal I would like to invite you, first & foremost, to the ROM Q&A for this tablet. I'm hopeful that the Q&A will provide answers to relevant questions like yours, and provide input, user experiences, & ideas for future ROM development for the Tab 3 8.
Click to expand...
Click to collapse
A generous interpretation... Thanks for invitation. I'll be sure to come up with a curly one or two.
For now, could you give a rough idea of what needed changing to bypass force encryption? And also, reasons for pre-rooting? Thanks, PW.
pndwal said:
A generous interpretation... Thanks for invitation. I'll be sure to come up with a curly one or two.
For now, could you give a rough idea of what needed changing to bypass force encryption? And also, reasons for pre-rooting? Thanks, PW.
Click to expand...
Click to collapse
Reasons for pre-rooting are merely as a convenience to the user. Many users will use the stock build I compiled and root themselves, while others will take the more convenient route and flash the ROM which is pre-rooted. The advantages of the rooted ROM are that it will be moderately debloated, deodexed, zipaligned, and will of course have BusyBox binaries pre-injected and the Magisk Systemless User Interface installed.
To bypass force encryption, I first needed to bypass dm-veriity. Both are enabled by default on this tablet within the ramdisk/fstab. So the boot image needed to be unpacked, the values of "1" enabling both dm-verity & force encryption needed to be changed to values of "0", thus disabling both features. The boot image was then repacked and then archived within my ROM installation package (zip).
I'd also like to take a poll to ask whether members want Viper4AndroidFX v2.5.0.5 (with NEON audio drivers) on the custom ROM, in lieu of the Dolby Digital Sound audio package that comes pre-installed on the tablet. Any input would be appreciated.
MotoJunkie01 said:
I'd also like to take a poll to ask whether members want Viper4AndroidFX v2.5.0.5 (with NEON audio drivers) on the custom ROM, in lieu of the Dolby Digital Sound audio package that comes pre-installed on the tablet. Any input would be appreciated.
Click to expand...
Click to collapse
Viper can be installed as a module in magisk. PW
pndwal said:
Viper can be installed as a module in magisk. PW
Click to expand...
Click to collapse
Yes it can, but it breaks the stock camera completely, due to the SELinux policy mod which is installed by the module. If included as a feature of the ROM, I have a workaround which sets SELinux to permissive on boot, instead of permanently disabling the policy from within the kernel. This prevents breaking of the stock camera.
MotoJunkie01 said:
Yes it can, but it breaks the stock camera completely, due to the SELinux policy mod which is installed by the module. If included as a feature of the ROM, I have a workaround which sets SELinux to permissive on boot, instead of permanently disabling the policy from within the kernel. This prevents breaking of the stock camera.
Click to expand...
Click to collapse
I did that in past too. Don't think its needed now.
Viper working fine for me as Magisk module (phone and TB3-850f tablet). SELinux enforcing, camera working fine (incl. video), 2.5.0.4 driver, 2.5.0.5 app.
Seems SELinux policy change no longer required as V4A module for Magisk installs AML (Audio Modification Library) as Magisk framework which no longer requires permissive. Let me know if I'm missing something. PW.
pndwal said:
I did that in past too. Don't think its needed now.
Viper working fine for me as Magisk module (phone and TB3-850f tablet). SELinux enforcing, camera working fine (incl. video), 2.5.0.4 driver, 2.5.0.5 app.
Seems SELinux policy change no longer required as V4A module for Magisk installs AML (Audio Modification Library) as Magisk framework which no longer requires permissive. Let me know if I'm missing something. PW.
Click to expand...
Click to collapse
You are pretty well correct. But, in order to enjoy the full spectrum of the NEON audio drivers, SELinux must go permissive. The Viper version I am speaking of was compiled by Deuteronomy Sound Technologies (and Arise) and is known as Viper4 AriseFX (a modded, themeable, and undoubtedly the most feature packed Viper package available for Android). The Viper module available on Magisk is a bare bones package, and when used in combination with my patched boot image (due to SELinux policy) it breaks the stock camera and causes other instabilities within the ROM.
I'm working also on a custom kernel for the TB3-850F, which will have some audio tweaks available from the kernel itself, as well as some tuneable governors, preset TCP congestion algorithms, etc.
MotoJunkie01 said:
You are pretty well correct. But, in order to enjoy the full spectrum of the NEON audio drivers, SELinux must go permissive. The Viper version I am speaking of was compiled by Deuteronomy Sound Technologies (and Arise) and is known as Viper4 AriseFX (a modded, themeable, and undoubtedly the most feature packed Viper package available for Android). The Viper module available on Magisk is a bare bones package, and when used in combination with my patched boot image (due to SELinux policy) it breaks the stock camera and causes other instabilities within the ROM.
I'm working also on a custom kernel for the TB3-850F, which will have some audio tweaks available from the kernel itself, as well as some tuneable governors, preset TCP congestion algorithms, etc.
Click to expand...
Click to collapse
I see. Perhaps you could explain the benefits of neon audio - I wasn't aware.
Also, would permissive SELinux not break SafetyNet check? Thanks, PW.
pndwal said:
I see. Perhaps you could explain the benefits of neon audio - I wasn't aware.
Also, would permissive SELinux not break Safety net check? Thanks, PW.
Click to expand...
Click to collapse
Yes and no. Depending on how you set the SELinux policy. I've found that setting SELinux to permissive on boot only, by way of a third party app like Kernel Adiutor-Mod or The SELinux Toggler, does not break SafetyNet. However, permanently disabling SELinux as enforcing, by way of modding the kernel itself, has been reported to cause a SafetyNet fail on both custom and stock ROMs.
You raise a good question though, and it is a factor to which I'll be paying close attention during development for this tablet.
I think I've decided to include Viper4AriseFX in my ROM as optional, and available by flashing a separate zip installer subsequent to installing the ROM itself.
By the way @pndwal, you seem to know your way around Android pretty well. What are some other features you would like to see in a custom built ROM for the Tab 3 8?
MotoJunkie01 said:
Yes and no. Depending on how you set the SELinux policy. I've found that setting SELinux to permissive on boot only, by way of a third party app like Kernel Adiutor-Mod or The SELinux Toggler, does not break SafetyNet. However, permanently disabling SELinux as enforcing, by way of modding the kernel itself, has been reported to cause a SafetyNet fail on both custom and stock ROMs.
You raise a good question though, and it is a factor to which I'll be paying close attention during development for this tablet.
I think I've decided to include Viper4AriseFX in my ROM as optional, and available by flashing a separate zip installer subsequent to installing the ROM itself.
Click to expand...
Click to collapse
Optional install sounds like a good idea, especially if SELinux permissive is optional to. I'm hesitant to use permissive environment as many apps etc require enforcing, and attempts to circumvent this, eg Magisk's ability to hide permissive etc, are reportedly not foolproof.
Not sure about attraction with Neon and ARISE, but seems permissive SELinux requirement to use these may be short-lived anyway. See post from today, at https://forum.xda-developers.com/an...d-systems-auditory-research-t3379709/page3125
problem:
NEON Enabled: No
Enabled: No
Status: Abnormal
ETC...
How solve it please?
Magisk 14.3 thats why. You need permissive. ARISE hasnt been updated for the new changes to how magisk handles selinux. Just for now you'll need to switch to permissive to get viper to work. Hopefully we'll have a build up soon to make it work, I know that ZackPTG and Ghost started to update it although i'm not sure on progress.
Hope it helps, PW.
pndwal said:
Optional install sounds like a good idea, especially if SELinux permissive is optional to. I'm hesitant to use permissive environment as many apps etc require enforcing, and attempts to circumvent this, eg Magisk's ability to hide permissive etc, are reportedly not foolproof.
Not sure about attraction with Neon and ARISE, but seems permissive SELinux requirement to use these may be short-lived anyway. See post from today, at https://forum.xda-developers.com/an...d-systems-auditory-research-t3379709/page3125
problem:
NEON Enabled: No
Enabled: No
Status: Abnormal
ETC...
How solve it please?
Magisk 14.3 thats why. You need permissive. ARISE hasnt been updated for the new changes to how magisk handles selinux. Just for now you'll need to switch to permissive to get viper to work. Hopefully we'll have a build up soon to make it work, I know that ZackPTG and Ghost started to update it although i'm not sure on progress.
Hope it helps, PW.
Click to expand...
Click to collapse
I've got Viper4AriseFX fully functional with Magisk v14.3. SafetyNet pass. I'm using a method which does not permanently set SELinux to permissive, but which toggles it to permissive only upon boot.
My pre-patched boot image is probably key to the successful installation as well. I'll list a complete change log of the exact mods once my beta release is ready. From what I'm gathering on logcat, Viper4AriseFX is "seeing" SELinux as permissive, while other system components are seeing the policy as enforcing. I believe I've stumbled upon the key to this SELinux policy dilemma.
MotoJunkie01 said:
By the way @pndwal, you seem to know your way around Android pretty well. What are some other features you would like to see in a custom built ROM for the Tab 3 8?
Click to expand...
Click to collapse
No really unique ideas, but interested in improved performance (speed and battery), battery being pretty good already.
MT8161p CPU specs say Quad-Core, 1.3 GHz, but TB3-850f is limited to 1.0 GHz, so a kernel modified to allow overclocking should achieve 30% boost easily (and CPU can usually go ~30% higher than specs, so perhaps 1.7 GHz or so would be achievable) unless I'm missing something.
Could improve Adoptive Memory (SD) handling, but may have to wait for port to N or O for this as anomalies with handling Dev. manifest values to make moveable apps automatically go to SD (as well as not allowing some even to be moved manually that should move fine) seem to an Android M limitation. (Works beautifully/ as expected on my phone with lineage N, and if Dev. hasn't enabled 'move apps to SD', can 'Force allow apps on external' in Developer Options [Makes any app eligible to be written to external storage, regardless of manifest values].) Guess N / O may be a way off, but would be nice.
Lenovo is now pushing ~30MB OTA update to TB3-850F_S100031_171010_ROW, so you'll probably want to capture / incorporate this in your ROM. (Is it possible to modify OTA update to allow flashing on rooted devices without restoring stock recovery? [Edit: Seems this would require merging differential update with complete files updated, and likely should only be flashed as complete ROM unless stock restored. Saw this: https://twrp.me/faq/officialota.html]) This is not available as a complete downloadable ROM on Russian Websites (lenovo-forums.ru or 4pda.ru) or others as yet as far as I can see.
Hope ideas are helpful, PW.
pndwal said:
No really unique ideas, but interested in improved performance (speed and battery), battery being pretty good already.
MT8161p CPU specs say Quad-Core, 1.3 GHz, but TB3-850f is limited to 1.0 GHz, so a kernel modified to allow overclocking should achieve 30% boost easily (and CPU can usually go ~30% higher than specs, so perhaps 1.7 GHz or so would be achievable) unless I'm missing something.
Could improve Adoptive Memory (SD) handling, but may have to wait for port to N or O for this as anomalies with handling Dev. manifest values to make moveable apps automatically go to SD (as well as not allowing some even to be moved manually that should move fine) seem to an Android M limitation. (Works beautifully/ as expected on my phone with lineage N, and if Dev. hasn't enabled 'move apps to SD', can 'Force allow apps on external' in Developer Options [Makes any app eligible to be written to external storage, regardless of manifest values].) Guess N / O may be a way off, but would be nice.
Lenovo is now pushing ~30MB OTA update to TB3-850F_S100031_171010_ROW, so you'll probably want to capture / incorporate this in your ROM. (Is it possible to modify OTA update to allow flashing on rooted devices without restoring stock recovery? [Edit: Seems this would require merging differential update with complete files updated, and likely should only be flashed as complete ROM unless stock restored. Saw this: https://twrp.me/faq/officialota.html]) This is not available as a complete downloadable ROM on Russian Websites (lenovo-forums.ru or 4pda.ru) or others as yet as far as I can see.
Hope ideas are helpful, PW.
Click to expand...
Click to collapse
You may have read the wrong specs. There has been much confusion between the TB3-850M (which runs on the MT8161p), and the TB3-850F (which runs on the MT6735m). A lot of online sources have misstated the board platforms on these two tablets.
My TB3-850F build.prop clearly lists the board platform as MT6735m, as does the hardware reading given by the SP Flash Tool when I sync the device on my PC. I wish mine did have the MT8161 (1.3GHz) versus the 1.0GHz of my MT6735.
But just to be certain there are not variants of the TB3-850F, read your build.prop via file explorer or build prop editor and let me know if yours is in fact the MT8161p.
Thanks for the heads up on the OTA. I wasn't aware of it and I'll definitely be updating my stock ROM thread accordingly.
Oh to answer your question on the OTAs, yes you can flash an OTA to a rooted/modified device by editing the updater-script and omitting the crypto-hash checks performed during the typical OTA installation, and by editing the incremental target and source lines (or omitting them entirely).
Just got the 33mb OTA captured. Looks like there are the usual bug fixes & stability improvements, but also the KRACK exploit has been patched, the partition index updated, and kernel updates. I'm currently compiling an up-to-date stock ROM with TWRP flashable installer.
MotoJunkie01 said:
You may have read the wrong specs. There has been much confusion between the TB3-850M (which runs on the MT8161p), and the TB3-850F (which runs on the MT6735m). A lot of online sources have misstated the board platforms on these two tablets.
My TB3-850F build.prop clearly lists the board platform as MT6735m, as does the hardware reading given by the SP Flash Tool when I sync the device on my PC. I wish mine did have the MT8161 (1.3GHz) versus the 1.0GHz of my MT6735.
But just to be certain there are not variants of the TB3-850F, read your build.prop via file explorer or build prop editor and let me know if yours is in fact the MT8161p.
Thanks for the heads up on the OTA. I wasn't aware of it and I'll definitely be updating my stock ROM thread accordingly.
Oh to answer your question on the OTAs, yes you can flash an OTA to a rooted/modified device by editing the updater-script and omitting the crypto-hash checks performed during the typical OTA installation, and by editing the incremental target and source lines (or omitting them entirely).
Click to expand...
Click to collapse
Yes, I'd forgotten this confusion.
Actually, didn't check online sources, but assumed Phone Tester was reporting correctly. It gives CPU Info: MT8161p.
Just checked Kernel Auditor which gives MT8161p as vendor, but MT6735 as hardware.
CPU-Z gives MT6735 as SoC.
My build.prop also gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P.
Russian 4PDA forum gives 850f Processor Type: MT8161, with MT8735 for 850M variant. (http://4pda.ru/devdb/lenovo_tab3_8:850f)
So it's hard to know what or who's correct, but looks to me that newer CPUs have likely been installed on boards originally designed for MT6735. (My CPU could actually be MT8735 as given by build.prop if Lenovo had excess chips from 850M, or simply decided to use these in both models. - I guess they may even have started with MT6735 for 850f before progressively using MT8161 and MT8735.)
So seems to me to be in the realms of possibility that a kernel allowing overclocking may just render spectacular results (as long as later CPUs were in fact used, and these are not crippled by an older board chipset.) But then, I may be way off base . . . Let me know your thoughts. PW.
pndwal said:
Yes, I'd forgotten this confusion.
Actually, didn't check online sources, but assumed Phone Tester was reporting correctly. It gives CPU Info: MT8161p.
Just checked Kernel Auditor which gives MT8161p as vendor, but MT6735 as hardware.
CPU-Z gives MT6735 as SoC.
My build.prop also gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P.
Russian 4PDA forum gives 850f Processor Type: MT8161, with MT8735 for 850M variant. (http://4pda.ru/devdb/lenovo_tab3_8:850f)
So it's hard to know what or who's correct, but looks to me that newer CPUs have likely been installed on boards originally designed for MT6735. (My CPU could actually be MT8735 as given by build.prop if Lenovo had excess chips from 850M, or simply decided to use these in both models. - I guess they may even have started with MT6735 for 850f before progressively using MT8161 and MT8735.)
So seems to me in the realms of possibility that a kernel allowing overclocking may just render spectacular results (as long as later CPUs were in fact used, and these are not crippled by an older board chipset.) But then, I may be way off base . . . Let me know your thoughts. PW.
Click to expand...
Click to collapse
Yeah I agree with you wholeheartedly that overclocking - at least moderately - could provide some benefit. I'm seeing that our current 1.0GHz maximum clock could safely be overclocked to about 1.33GHz. Definitely something I will be considering. I've been able to optimize this device's meager 1GB RAM by zipaligning the apk files, and by setting a maximum background process limit to build.prop. I've also found that setting the stock kernel's Adaptive Low Memory Killer to Very Aggressive helps as well.
I've installed the OTA and it seems to improve general stability of the device, and provides us with much needed security patches. I'll be updating my stock ROM to the most recent version later today. Here is a link to the captured OTA if anyone is interested in exploring it. However, in order to flash it to a rooted/modified device, the updater-script first needs to be modified. But again, I'll have the updated build posted later today.
OTA_TB3-850F_S100031_171010_ROW: https://drive.google.com/file/d/11xo-7X06ST1RV8X5TJHjM5o2MHfcsNhl/view?usp=drivesdk
MotoJunkie01 said:
Yeah I agree with you wholeheartedly that overclocking - at least moderately - could provide some benefit. I'm seeing that our current 1.0GHz maximum clock could safely be overclocked to about 1.33GHz. Definitely something I will be considering. I've been able to optimize this device's meager 1GB RAM by zipaligning the apk files, and by setting a maximum background process limit to build.prop. I've also found that setting the stock kernel's Adaptive Low Memory Killer to Very Aggressive helps as well.
I've installed the OTA and it seems to improve general stability of the device, and provides us with much needed security patches. I'll be updating my stock ROM to the most recent version later today. Here is a link to the captured OTA if anyone is interested in exploring it. However, in order to flash it to a rooted/modified device, the updater-script first needs to be modified. But again, I'll have the updated build posted later today.
OTA_TB3-850F_S100031_171010_ROW: https://drive.google.com/file/d/11xo-7X06ST1RV8X5TJHjM5o2MHfcsNhl/view?usp=drivesdk
Click to expand...
Click to collapse
Great. What do you make of build.prop entry: ro.lenovo.cpuinfo=MT8735P? PW.
pndwal said:
Great. What do you make of build.prop entry: ro.lenovo.cpuinfo=MT8735P? PW.
Click to expand...
Click to collapse
It's simply a typo that was made in build.prop I believe. Going by ro.board.platform, they seem to have it correct with the 6735 entry. I was just messing with some components of the unpacked boot image from this device, and it seems that except for the SoC differences, the 850M and 850F are otherwise identical. Of course, the 850M, by way of its mt8161p, has full SIM & 4G/LTE data support. In our variant, the SIM slot (next to the micro SD card slot) is blocked off, whereas it's fully accessible in the 850M.
P.S, if you're rooted, add this line to build.prop and let me know if you see a difference in RAM optimization: ro.config.low_ram=true