[Galaxy Tab S2 Android Development] retiredtab:
Many topics to address so I broke them down into sections. This is a long and lengthy read which will probably take 10 to 15 minutes and there is no TLDR because I believe in giving everyone the same information so they can make an informed decision.

The 5 of us, @ananjaser1211, @lpedia, @Yogi555 and @CuckooPenguin spent almost 1 month to fix these problems and continue to spend time presently on 18.1 so I think it's only fair that people take 10 to 15 minutes to read this post. If people belive this is an unreasonable request, Thank you, and please don't use any of my builds ever.

17.1 PROBLEMS for ROMS BEFORE the August 25 builds.

1. Wifi drops, wifi instability, wifi won't reconnect after sleep or reboot in Anroid 10 (17.1).

lpedia and I spent 5 days researching and testing #1 and presented our findings on Jul 19 on what we thought was a fix for all Android 10 users. This is documented at

https://xdaforums.com/t/troubleshoo...-version-of-android-10.4308193/#post-85353551

The fix was to use the original S2 wifi blobs instead of the S6 ones and that patch was submitted by me and merged into github on Aug 9 by Anan.

The S6 wifi blobs were problematic particularly for people with congested and dual band networks (that is, same ssid on 2.4Ghz and 5Ghz). Several people have reported much better results with using the original stock S2 wifi blobs.

I never had wifi instability problems because I don't have dual band and while my wifi spectrum is crowded, it's stable where I live.

In addition, people running 16.0 or Android 9 never ran into these wifi problems because they were using the stock S2 wifi blobs.

Note: I'm not the person who changed the S2 wifi blobs to S6 so I have no idea why that change was done as it's not documented on github.

2. Daily "random" reboots/crashes or reboot into TWRP or dead battery in the morning in Android 10 (17.1).

https://xdaforums.com/t/troubleshoo...rs-running-any-version-of-android-10.4308203/

After lpedia and I were confident that wifi was resolved, we moved onto #2. Yogi555 and CuckooPenguin kindly shared their tombstones along with lpedia. The 4 of us then setup a xda group PM and then spent the next 22 days troubleshooting this problem until we found a solution. "Random" is in quotes because with enough tombstone data, we were able to figure out that gnss was crashing.

With the help of ananjaser1211 as a sounding board/ideas throughout the entire 22 days, we eventually figured out that the gnss passthrough implementation was causing the crashes and switching to hardware binder solved the problem. The Samsung proprietary gps.default.so blob

does not work properly in gnss passthrough configuration.

Since I never had this gnss problem because I don't use GPS on my t710, we decided to use the 100+ uptime hour criteria to see if gnss

hwbinder patch was stable. Since the other 3 people had < 24 hour gnss daily crashes (as shown by tombstone data), if they all passed the 100+ hour uptime, then we could say it was fixed.

In fact, @zed011 sent me a PM on Aug 18 saying his t710 with the gnss hwbinder patch + S2 wifi blob patch had 339 hours uptime. Today is Aug 25, so if zed011's t710 is still going, that would be 500+ hours of uptime or 3 weeks without a gnss crash.

In addition, zed011 has another t710s that is running ripee's July 18 build without the 2 patches and it would crash and reboot daily with gnss errors as shown in tombstone.

The gnss hwbinder patch was submitted to github on Aug 4 by me and accepted and merged by Anan the same day.

I have no proof because there are no logs and no one has volunteered any, but I suspect when people report dead battery in the morning it's because gnss is crashing and may cause endless boot animation which means the device is running all night until it drains the battery. This may be dependent on what apps use gps and how those apps behave with gnss crashes because not everyone sees dead battery in the morning.

Others report finding their device in TWRP in the morning and that's because of Android's "rescue party" functionality in 8.0 and higher. If the same process crashes 5 times in < 5 minutes, Android will reboot you into recovery mode and present the option to the user to perform a factory reset. Since most people are using TWRP and not stock recovery, that function doesn't quite work properly.

This all explained in great detail in the github patch at

https://github.com/universal5433/an...mmit/1bbb341259f6aee071d88e4abdce42190fd620a7

18.1 - DON'T GET TOO EXCITED

Before people get too excited about seeing 18.1 builds on ripee's drive, let me explain the past, present and future of 18.1 because all of this information was done via xda group PM.

Yes, I got the initial 18.1 up and running on my t170 on Aug 11. Like any first boot, it had problems that needed to be fixed. We, the same group, worked through most of those and they are documented in my github.

Functionally, it does the same as Q/Android 10, but we are only on hour 50+ of our uptime 18.1 testing as of Aug 25. So at minimum, we have to wait another 2 days of uptime to get to 100+ to ensure that gnss hwbinder works/stable in 18.1 as it does in 17.1 testing. We have 2 people with t710 and 2 with t810. I cannot participate in the 100+ hour testing because I never had gnss crashes and I'm working on other 18.1 things with S2.

Having said that, the 18.1 builds that I publicly share were used by myself first as a "daily driver" for 4 months and a select group of highly advanced users. Of course, anyone is free to take my github sources and build their own 18.1 rom, but at this point, it's really early in the 18.1 build process. I would consider my 18.1 build as ALPHA.

If people depend highly on their S2 device for important things, it's best that to stay on 17.1 with the LineageOS Aug 25 build which has the gnss hwbinder and S2 wifi blob patches. With those 2 patches, it addresses the 2 most common reported stability issues over the last 8 to 12 months. I have verified the 2 patches are indeed in the t710 Aug 25 build so they should be in all the Aug 25 builds.

While those 2 patches are in 18.1, 18.1 just doesn't have the same amount of field testing as 17.1. In addition, the last major bug to be fixed in 18.1 was constant lmkd spam and it took several days to track down and was uploaded to my github on Aug 21. The lmkd spam bug is only present in 18.1 on exynos5433 devices (including Anan's note 4) due to changes in Android 11 and do not affect Android 10. The fix was to modify some kernel files to pass SCM_CREDENTIALS so that lmkd is happy. The fix (9 commits in all) is documented on Aug 21 at

https://github.com/universal5433/android_kernel_samsung_universal5433/commits/lineage-18.1

There are still these issues in 18.1 as of Aug 25. People, PLEASE DO NOT ask for an ETA. It does not help and is a waste of our time to answer.

1. Fingerprint (fp) unlock does not work after device goes into deep sleep. This does not work in 17.1 either. I tried fp unlock in CM 12, LineageOS 14.1, 16.0, 17.1 and 18.1 and none of them work after deep sleep.

Deep sleep is likely 10 seconds after your device's screen goes blank. That is, when the device screen goes blank, you can use fp to unlock if

you do it under 5 seconds immediately after it goes blank. If it's more than 10 seconds after the screen goes blank, fp unlock does not work. This is the same in 17.1 and 18.1.

Let me explain deep sleep because most people will think of deep sleep in human terms as being in the middle of the night or REM sleep. First, download a free app called devcheck by flar2 from

https://play.google.com/store/apps/details?id=flar2.devcheck

It's ad free and written by a XDA person here, but it's not open source. I use it on all my devices.

After it's been downloaded (only 6MB file) and installed, look at the dashboard tab. At the bottom, it shows uptime and deep sleep. Note that.

Close/kill devcheck and reboot your device. Open devcheck. It will show something like 35 seconds uptime and 0 seconds sleep. Now close/kill devcheck app again and let device goto sleep by itself and don't touch anything (for most people that means about waiting 1 minute). After the screen goes blank, wait 60 seconds, then wake up your device. Open devcheck again. You should see something like 2 minutes 35 seconds uptime and 50 seconds deep sleep.

The entire reason I explain how deep sleep works is because we found out that if you keep the device from entering deep sleep, using the fp

to unlock the device works. If you are one of those people who has fp working after deep sleep, you may have an app that prevents your device from reaching true deep sleep. Sure, the screen is off and you don't have a dead battery in the morning, but your device might be silently working at 400Mhz which you can verify by using devcheck and touching the CPU status.

True deep sleep might give you 2 weeks of standby. Assuming the same device, battery condition and usage, a CPU running at 400Mhz might give 10 days of standby.

To further test our theory of fp unlock working if it doesn't go into deep sleep, we used apps or programs to keep the S2 from deep sleep. That is, the screen would be off giving the appearance it's in deep sleep, but the CPU is running at 400Mhz. Even after several minutes, fp unlock would work.

What we don't know is how much battery savings is lost between deep sleep and 400Mhz. Is it 1% a day? 5% a day? 10% a day? We don't know.

And yes, we have tried fixing fp unlock in 17.1 and 18.1 with a variety of code changes, but nothing has worked yet.

So if you absolutely need fp unlock to work, DO NOT USE 17.1 or 18.1 as-is. If you desperately need this feature to work, you are welcome to look at the github public source code and help find a solution.

2. RIL or LTE/3G/4G (SM-T715, SM-T815)

I do not own any S2 ril or LTE/3G/4G devices and neither does anyone in our group of 4. There's been zero work and testing in that area. It's likely broken and doesn't work in 18.1. I CANNOT test or build for things that I do not own. Let me repeat that for those who will run into problems with 18.1 LTE/3G/4G, I CANNOT test or build for things that I do not own. That's the last word I will have to say on this topic.

3. adbd start before boot animation (asbba) - almost a famous musical group

In order for builders/coders/developers to debug code, we need adb (Android Debug Bridge) to work. Adbd is the daemon. Adbd MUST start before the boot animation process, or asbba I coined it. because a lot of problems, including bringing up 18.1, are stuck at boot animation. I need to be able to see text debug messages on my PC/console in order to fix them.

Without asbba, the device displays the boot animation forever, but I have ZERO text on my PC/console and I have NO IDEA where the OS is stuck at.

Like fp unlock bug, asbba does not work in any build including CM 12, LineageOS 14.1, 16.0, 17.1 and 18.1. Anan reports that asbba does not work in Note 4 either so it's a common problem to exynos5433 code/devices.

This won't affect 99.99% of the users, but without asbba, further development will be significantly slowed down. For example, gnss hwbinder would have been implemented a LOT QUICKER into the code, but the first attempt incorporating the change led to stuck at boot animation with ZERO adb logcat output because asbba was/is not working. It wasn't until a few days later that the correct code combination was found so that gnss hwbinder could boot. It's all documented in the github gnss patch.

4. DRM for $treaming services

Let me be clear. I don't have any $treaming services.

The DRM is L3 as shown by devcheck. I have worked on this area before and I will say that it will likely NEVER BE L1. That means you will see your $treaming services in SD resolution, not HD.

Getting L1 means working around encryption with old, outdated proprietary Samsung blobs that have not been updated in several years. If you need L1, stay with whatever rom you are using that has L1. If you want L1 working in 17.1 or 18.1, the source code is available on github for you to look at and come up with a solution. So like LTE/3G/4G, let repeat that for those who will run into problems with expectations of L1, I CANNOT test or build for things that I do not own.

5. Sepolicy or selinux enforcing

Sepolicy or selinux enforcing is passive or not enabled in 17.1 and 18.1. In order to have this enabled or enforcing, asbba NEEDS to be working first in order to get logs because the OS will be stuck at boot animation if the sepolices are not written correctly. Yes, some developers/coders could probably write a sepolicy, probably over 200 to 300 lines of code, on paper and it will work 1st try. However, I'm not a coder or developer.

The sepolices MUST be compiled into code. You cannot simply enable it by hacking a prop or using some magisk module and have a booting OS.

6. TCP error messages in logcat - patch not yet uploaded to github.

I have seen those same TCP info error logs in my 18.1 Tab A/E.

@ripee,

The 18.1 Aug 24/25 builds by ripee will NOT have this TCP/IP patch.

I have no idea how 18.1 will work in terms of networking without this patch. Some people may have problems, some may not.

There is a fix for TCP/IP error messages which is already patched into our 18.1 uptime test builds, but that fix has NOT been uploaded to github because there's 2 ways to fix it. And we want to make sure that it works over 100+ uptime hours.

The 2 ways are: modifying the kernel code or adding some lines to TcpSocketTracker.java. I chose the latter as per

https://github.com/DerpFest-11/pack...mmit/22fd53a977eeaf4e36be7bf6358ecf2c2737fa5e

It came out of this thread (thanks to Henrick Grimler for pointing this out to me).

https://xdaforums.com/t/rom-unoffic...g-galaxy-s5-klte.4209545/page-2#post-84211093

This DerpFest patch has been in my Tab A/E 18.1 devices since late March 2021 so it should be fine for S2 devices.

Implementing the patch into the kernel is another possibility, but I have not chosen that route as I'm not a kernel expert and the DerpFest patch was much easier to implement. However, I know exynos 5420 team has implemented the kernel patch and it works fine. Henrick did the patches.

7. SD card is significantly SLOWER in 18.1 vs 17.1

Yogi555 reported that sd card is significantly SLOWER in 18.1 vs 17.1. By a factor of 10x slower depending on the app. lpedia researched and found that this might be due to storage changes in Android 11 as per

https://medium.com/androiddevelopers/android-11-storage-faq-78cefea52b7c

If you have lots of apps/data on your sd card, you may want to read the above and decide before hand if there's an update for your app or

you can move it to internal storage. There's no "fix" in 18.1 code for the above.

How can people help

1. If you report random crashes in 17.1 with the Aug 25 build or later, you MUST include tombstone data and put it into the thread that is already open for random crashes. The same goes for any "random" crashes in 18.1.

https://xdaforums.com/t/troubleshoo...rs-running-any-version-of-android-10.4308203/

NO tombstone data = 0% chance of getting "random" reboots fixed. I guarantee that.

The Aug 25 17.1 builds have both the gnss hwbinder and S2 wifi blobs patch.

2. If you can read code, you don't need to be an Android developer, let me know if you want to volunteer to help chase down some bugs reported above. Send me a PM and I will discuss this with you.

3. Be reasonable and realistic about 18.1. Again, it just got up and running on Aug 11 (2 weeks ago) and there's still lots of testing, cleaning out old 17.1 code, bugs to be fixed, etc . Be aware of the outstanding issues, 7 currently, and be prepared to accept the FACT they may NEVER be solved due to Samsung proprietary blobs, the lack of volunteer time from people, the difficulty of the reading/understanding/maintaining 7+ year old code, responsibilites in real life like family, friends, free time, work, pandemic, etc.

4. Do some homework and research before posting. No one likes seeing more FAQs like which TWRP do I use? Does magisk work? When will feature xyz be fixed? In my own rom threads which I started, I post a lengthy FAQ and will NOT respond to any posts that are already addressed in the FAQ. It's obvious to me who has and hasn't read the FAQ and done any homework or research. We put in 100s of hours of work into these builds FOR FREE and if people can't spend 10 minutes to read my FAQ to get > 100's hour of enjoyment, they should look for alternatives.

Note: small edits are being made to grammar, typos as I re-read. Clarifications will be made with the strikeout font. Thank you.