yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
For those who refuse to read the FAQ, this ROM is ONLY for SM-T560NU, NOT SM-T560. I CANNOT make a SM-T560/SM-T561 build as they are different CPU/SoCs. All questions regarding the SM-T560/T561 will be ignored.

New build called lineage-19.1-20230319-UNOFFICIAL-gtelwifiue.zip

NOTE: All builds that I upload have been personally tested on my device to boot and function as described in post #1. Having said that, there's still a chance it won't work on your device due to human error, your configuration, your apps, etc. If it won't boot, always start with a complete wipe of everything and format your data in TWRP. This is known has a clean install. Backup your data before a clean install.

March 19 , 2023 release notes

1. Mar 5 security patches as per https://review.lineageos.org/q/topic:S_asb_2023-03

2. Whatever LineageOS changed since Feb 5 patches. About 24,500 files had to be recompiled.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] mobrien118:
How does this compare in performance/usability (working features)/app compatibility to your 18.1 build?

I have a couple apps that won't play on the 18.1 build (one because it is just too slow, the other because it just crashes about 10 seconds in).

With a new android version, I would expect worse speed but better app compatibility. Since this is labeled "ALPHA" and your 18.1 is labeled "BETA" I would assume the 18.1 is further along in "usability," but I know that those labels can be misleading for a number of reasons.

Looking for anyone's thoughts who has compared them, incl. author.

@retiredtab - Thank you for your work on this - it has given our tablets additional life beyond our expectations.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] sorheim:
I recently switched back to 18.1 after using the 19 alpha for several weeks including the most recent update. I found performance to be pretty similar. I mostly use it for email, ebooks and browsing. The only times I really struggled with speed on 19 was while browsing. I've tried several browsers but so far I've found none that are to my liking. For that reason, I switched back to 18.1. At first it seemed a little faster and smoother but after using it several days, I find it too lags often when web browsing. I'm still trying different browsers and will likely go back to 19 when I settle on one.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] RDS5:
19.1 for me was faster, but thats likely due to android's under-the-hood optimizations with android 12
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
For those who refuse to read the FAQ, this ROM is ONLY for SM-T560NU, NOT SM-T560. I CANNOT make a SM-T560/SM-T561 build as they are different CPU/SoCs. All questions regarding the SM-T560/T561 will be ignored.

New build called lineage-19.1-20230412-UNOFFICIAL-gtelwifiue.zip

NOTE: All builds that I upload have been personally tested on my device to boot and function as described in post #1. Having said that, there's still a chance it won't work on your device due to human error, your configuration, your apps, etc. If it won't boot, always start with a complete wipe of everything and format your data in TWRP. This is known has a clean install. Backup your data before a clean install.

Apr 12 , 2023 release notes

1. Apr 5 security patches as per https://review.lineageos.org/q/topic:S_asb_2023-04

2. Whatever LineageOS changed since Mar 5 patches. About 23,000 files had to be recompiled.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
For those who refuse to read the FAQ, this ROM is ONLY for SM-T560NU, NOT SM-T560. I CANNOT make a SM-T560/SM-T561 build as they are different CPU/SoCs. All questions regarding the SM-T560/T561 will be ignored.

New build called lineage-19.1-20230507-UNOFFICIAL-gtelwifiue.zip

NOTE: All builds that I upload have been personally tested on my device to boot and function as described in post #1. Having said that, there's still a chance it won't work on your device due to human error, your configuration, your apps, etc. If it won't boot, always start with a complete wipe of everything and format your data in TWRP. This is known has a clean install. Backup your data before a clean install.

May 7 , 2023 release notes

1. May 5 security patches as per https://review.lineageos.org/q/topic:S_asb_2023-05

2. Whatever LineageOS changed since Apr 5 patches. About 7,400 files had to be recompiled.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
Starting June 2023, odd numbered LineageOS releases will be released on odd numbered months and even numbered LineageOS releases will be released on even numbered months. For example,

LineageOS 19.1, next release will be July.

LineageOS 18.1, next release will be June.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
I have released LineageOS 20 ALPHA at

https://xdaforums.com/t/unofficial-...-galaxy-tab-e-sm-t560nu-june-23-2023.4599897/

I will likely discontinue building 19.1 at the end of 2023 because 19.1 and 20 are very similar and I don't want to be building and maintaining 18.1, 19.1 and 20 as it's too much work.

To clarify,

1. I will build 20 every month for 2023

2. I will build 19.1 on odd numbered months for 2023

3. I will build 18.1 on even numbered months for 2023

I haven't made a decision on 18.1 for 2024.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
For those who refuse to read the FAQ, this ROM is ONLY for SM-T560NU, NOT SM-T560. I CANNOT make a SM-T560/SM-T561 build as they are different CPU/SoCs. All questions regarding the SM-T560/T561 will be ignored.

New build called lineage-19.1-20230711-UNOFFICIAL-gtelwifiue.zip

NOTE: All builds that I upload have been personally tested on my device to boot and function as described in post #1. Having said that, there's still a chance it won't work on your device due to human error, your configuration, your apps, etc. If it won't boot, always start with a complete wipe of everything and format your data in TWRP. This is known has a clean install. Backup your data before a clean install.

July 11, 2023 release notes

1. June 5 + July 5 security patches as per https://review.lineageos.org/q/topic:S_asb_2023-07 and https://review.lineageos.org/q/topic:S_asb_2023-06

2. Whatever LineageOS changed since May 5 patches. About 6,900 files had to be recompiled.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] slebreotn:
None of your build will install on my SM-T560NU. it states wrong device.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
For those who refuse to read the FAQ, this ROM is ONLY for SM-T560NU, NOT SM-T560. I CANNOT make a SM-T560/SM-T561 build as they are different CPU/SoCs. All questions regarding the SM-T560/T561 will be ignored.

New build called lineage-19.1-20230908-UNOFFICIAL-gtelwifiue.zip

NOTE: All builds that I upload have been personally tested on my device to boot and function as described in post #1. Having said that, there's still a chance it won't work on your device due to human error, your configuration, your apps, etc. If it won't boot, always start with a complete wipe of everything and format your data in TWRP. This is known has a clean install. Backup your data before a clean install.

Sept 8, 2023 release notes

1. Aug 5 + Sept 5 security patches as per https://review.lineageos.org/q/topic:S_asb_2023-08 and https://review.lineageos.org/q/topic:S_asb_2023-09

2. Whatever LineageOS changed since July 5 patches. About 12,000 files had to be recompiled.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] serlou:
Goodday sir.. I'm new here at xda.. May I ask if you can suggest me a custom Rom that is compatible witn Samsung tab E SM-T560nu.. Thanks a lot
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] V0latyle:
Do not post duplicates. I have removed your duplicate post. Read the Forum Rules as you are expected to follow them.

Download link is at the bottom of the second post.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] serlou:
Thank you sir.. Godbless
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] serlou:
I tried to instal lineage 19.1 on my Samsung tab E SM-T560nu but there's an error.

E: unknown command log

Error installing zip file.

Could you help me guys to properly instal.. Thanks a lot
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] retiredtab:
For those who refuse to read the FAQ, this ROM is ONLY for SM-T560NU, NOT SM-T560. I CANNOT make a SM-T560/SM-T561 build as they are different CPU/SoCs. All questions regarding the SM-T560/T561 will be ignored.

New build called lineage-19.1-20231112-UNOFFICIAL-gtelwifiue.zip

NOTE: All builds that I upload have been personally tested on my device to boot and function as described in post #1. Having said that, there's still a chance it won't work on your device due to human error, your configuration, your apps, etc. If it won't boot, always start with a complete wipe of everything and format your data in TWRP. This is known has a clean install. Backup your data before a clean install.

Nov 12 , 2023 release notes

1. Oct 6 + Nov 5 security patches as per https://review.lineageos.org/q/topic:S_asb_2023-10 and https://review.lineageos.org/q/topic:S_asb_2023-11

2. Whatever LineageOS changed since Sept 5 patches. About 8,100 files had to be recompiled.

As I wrote June 26, 2023, I will be discontinuing the 19.1 builds so this Nov 12, 2023 is the LAST BUILD. Those who want 19.1 can build it themselves as per FAQ #1.
[Samsung Galaxy Tab E  ROMs, Kernels, Recoveries, &] momi-mcs:
Can u please provide kernal tree, device tree and vendor tree for android 14 or even better can u please compile lineage os 21 for SM-T560NU. At first I wanted to compile it myself but I did not find any premade trees and I don't have the technical know how to build my own. ThankYou
[Magisk] pndwal:
Yup... But this is what the @Displax mod solution is doing however, but targeting GMS... Also his USNF PR...

Also interesting:

https://github.com/kdrag0n/safetynet-fix/pull/207#issue-1317290126

@kdragon is taking interest... He's concerned about fingerprint mismatch issues too:

So @Displax says it's "for now" / and is "just quick example (and core resolve) with temp fix for impatient people))... But need more testing with various devices." He agreed:

https://github.com/kdrag0n/safetynet-fix/pull/207#issuecomment-1195951660

👀 PW
[Magisk] zgfg:
Yeah, that's the point - he uses Zygisk to limit CTS prints only to GMS - therefore if you use getprop you won't see the CTS prints being changed (like if you would use MHCP for changing the prints)

See that USNF is Zygisk type module, MHCP is not - hence MHCP cannot filter the props changes only to particular app/process

Therefore, other apps (like camera, Samsung store, etc) are not troubled - they still see the proper props values
[Magisk] pndwal:
Some Insight on the New Cat and Mouse Game...

Since many are asking:

I'm posting this WOT. 🤪

I predict some will like it, some won't... You've been warned! 😜

Spoiler content hidden.

👀 🤠
[Magisk] V0latyle:
I've been meaning to ask....Since Google is replacing SafetyNet with Play Integrity, is it safe to assume that there will come a day when app developers (particularly Google) remove SafetyNet support from their apps, at which point those of us with root will be unable to force "legacy" attestation as with the modified USNF? Of course this will mean that all versions of Android prior to the implementation of HA/TEE will be excluded as well, but it's not uncommon for developers to stop supporting older platforms.
[Magisk] V0latyle:
Would you consider possibly boiling this down to a fairly simpler explanation that we can sticky? It's likely this will be the topic of quite repetitive questions going forward.

I tried to explain it somewhat simply here, please let me know how far I missed the mark
[Magisk] pndwal:
I put info about this originally here:

https://xdaforums.com/t/magisk-module-universal-safetynet-fix-2-3-1.4217823/post-87188299

Google is urging Devs to do just that; S/N API was already depreciated in June with 'full turndown' slated for June 2024... banks are urged to move to PI asap, and at least before the June 2023 migration deadline. If they do, their older versions will continue to function with S/N API till June 2024. If they don't, these will cease to gat needed attestations from June 2023.

No, the new API includes all of the same device state checks and app processees use either one or the other, (although GPay seemed to use one for the app info and the other for card setup... but I'm betting it's only due to progressive changes...) so S/N turnoff won't matter...

You'll notice that if CTS Profile match fails for example, Device Integrity will fail also... The new API is a little stricter, especially for A11+ devices but @Displax's new USNF covers new enforcement bypass needed for these devices... The old bypasses are also still needed... And an official Pull Request is pending. (My Android 10 device doesn't need any change from official USNF)

This is the point of what I just posted; if Google swings the enforce HKA if supported for MEETS_DEVICE_INTEGRITY hammer first, banks likely won't move to MEETS_STRONG_INTEGRITY sparing pre A8 stock devices... If they don't, eventually banks will implement MEETS_STRONG_INTEGRITY which will exclude customers using pre A8 devices... Either way it's game over for modders at that point... At least that's what my deduction says! 😛

See official dates, info, links from here:

https://developer.android.com/training/safetynet/deprecation-timeline

👀 PW
[Magisk] zgfg:
That's something we can only speculate about.

Frankly, Google did not need Play Integrity - they could have simply forced CTS Profile checking through TEE (same thing as STRONG now) - but they didn't (yet)

Per specification, Google is not the final Judge. It only provides info how your device passes the Play Integrity API levels

If you are developer of a banking app, it is up to you would you allow DEVICE integrity, or would you require STRONG. Not even your banking app but better the banking server should make the final judgement (upon being passed the PI API test results)

Again, frankly, bankers could have already been checking do you pass CTS Profile with HARDWARE_BACKED or only BASIC, and allow only the first ones (they can also read that info with the old SafetyNet)

Btw, bankers (developers) can employ a more complex logic. Based on your phone model to require STRONG (new phones) or allow DEVICE (for older phones) - but it requires more work on their side
[Magisk] pndwal:
Wow.. another thread 😬... Perhaps we could condense this in @Didgeridoohan's GPay thread?

Anyway, since you asked me to critique:

I hadn't heard about Play Protect depreciation (it's still there currently, and Play Store is already using Play Integrity API!), but SafetyNet is already deprecated...

Um, no...

It simply allows PI MEETS_DEVICE_INTEGRITY verdict in Android 11+ (generally), by creating a fingerprint prop SDK-level (and possibly other) mismatch that triggers bypassing of Hardware keystore attestation enforcement... The original USNF fallback trigger (fake keystone registration) and enforcement bypass (altered Model prop) are also needed for MEETS_DEVICE_INTEGRITY verdict, and these alone are enough for many devices (pre-Android 11 generally).

Hardware keystore and hardware TEE have been around at least since Android 6, but keymaster could not reliably verify the key pairs were in hardware... This was strengthened in Android 7 Keymaster 2 attesting to hardware backed keys, but only Android 8's Keymaster 3, with ID attestation allowing the device to provide proof of hardware identifiers, such as serial number or IMEI, was considered an attestation strong enough for HKA in android..

The other points are treated in my post above. 😛 PW
[Magisk] zgfg:
You may also see this answer (we are all talking the same things, maybe with slightly different words):

https://xdaforums.com/t/discussion-google-pay-magisk-discussion-thread.3906703/post-87274309
[Magisk] V0latyle:
I admit it's a little hard to wrap my brain around this.

My understanding of the Play Integrity API was originally that in order to meet Play Integrity as a whole, devices would have to meet the BASIC, DEVICE, and STRONG integrity. I didn't know the apps looked at those qualities directly - I thought Play Integrity checked these, and if any of them was false, Play Integrity would report that integrity is compromised.

I promise I'm not being obtuse...

So the way it REALLY works is that the API is a method by which the apps can check these properties; it doesn't rely on a Google specific process (because AOSP)

Which means I still don't quite understand...how does the modded USNF allow apps such as GPay and Wallet to ignore the MEETS_STRONG_INTEGRITY?

It's clear to me that almost any device should return MEETS_BASIC_INTEGRITY, and that we have to use workarounds such as USNF to be able to return MEETS_DEVICE_INTEGRITY, and that we will never be able to return MEETS_STRONG_INTEGRITY because of HKA vs unlocked bootloaders.
[Magisk] zgfg:
Here (again) link to Google's doc:

Overview of the Play Integrity API | Google Play | Android Developers

developer.android.com

Pay attention to verdict - but better spend 15 minutes to read the whole

And in YASNAC, you can also read the JSON with eg details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)
[Magisk] pndwal:
FWIW, the real reason for the change was to provide an inclusive Integrity solution that

by combining existing SafetyNet attestation in Device Integrity fields with the new Application integrity and Account details fields in a single API.

🤠 PW
[Magisk] pndwal:
Apps can use MEETS_DEVICE_INTEGRITY by default, using any distribution channel. Registration with Google Play allows use of MEETS_BASIC_INTEGRITY and MEETS_STRONG_INTEGRITY in addition...

Flow chart:

View attachment 5684161

😛 PW
[Magisk] V0latyle:
I have read this and keep going back but I'm no developer and my general understanding of Android is less than elementary

This is where it's still confusing to me. Because according to that statement, it sounds like developers can choose what guarantee of security they want...but

This makes it sound like Play Integrity is not so much a framework as it is a service, meaning at some point app developers will have no choice?

Or am I right on both accounts, but app developers can either call the Play Integrity API, or they can call the device security fields alone?
[Magisk] V0latyle:
@ipdev @pndwal @zgfg @TraderJack I know it's a lot of work, but could you please move your posts on Play Integrity into this thread as described above? The idea is to have one thread to discuss this topic, as well as a place to point other users to should they have questions. If someone would like to volunteer their post, I can copy/paste into the OP so we have an up front explanation of what Play Integrity is, how it works, and what it means for rooted/modded users.
[Magisk] zgfg:
Is it possible to move the posts without copy-pasting them?

I mean it is if I mark it is Report and ask you to move - but then it's more work for you. Hence some other way?
[Magisk] V0latyle:
No, only moderators can move posts (and we have forum specific moderators so it wouldn't be me lol)

Else, you can copy/paste and request the old post be deleted
[Magisk] pndwal:
X2

Well Hardware evaluationTypes are used if available by default even if just calling Device_Integrity. That's why @kdragon uses both fake keystone (causes exception which triggers fall back to basic attestation) and altered Model prop (mismatch causes enforcement of a Hardware based verdict to be bypassed, ie. the forced basic attestation becomes acceptable)...

The statement "JSON ... details was the CTS Profile checked on TEE or not (= STRONG integrity for the be PI API)" may be misleading; really, MEETS_STRONG_INTEGRITY only indicates a passing STRONG_INTEGRITY verdict using hardware TEE; of course, unlocked devices will fail to return MEETS_STRONG_INTEGRITY and there will be no indication whether hardware TEE was used or not in PI, unlike old S/N attestation... Conversely, CTS Profile will be checked in TEE (ie. we see S/N HARDWARE evaluationType) to attest to DEVICE_INTEGRITY if it's available by default (ie. on A8+ devices), but if it fails there is no indication from PI API that hardware TEE was used, and no indication if hardware was used if it succeeds either unless STRONG_INTEGRITY succeeds also...

Don't confuse evaluationType with the choice of verdict type; Devs can choose any of three levels for verdict but cannot choose evaluationType used; Hardware will be used if it's available for that type unless userspace tricks are used to spoof device and cause fallbacks...

It's an API, (Application Programming Interface) requiring server-end support by Google; I gave you the dates / link a couple of times now for 'Migration deadline' & 'Full turndown' of S/N API at which point there will be no choice but to use PI API...

Sorry, are you referring to Play Integrity response labels?... These are all part of Play Integrity, of course!?

Main signals (responses) are defined as:

- Application integrity

- Account details

- Device integrity

For Device integrity, device_recognition_verdict is called.

By default, this can have one of the following labels:

MEETS_DEVICE_INTEGRITY

or

No labels (a blank value)

If you opt in to receive additional labels in Device integrity, device_recognition_verdict can have the following additional labels:

MEETS_BASIC_INTEGRITY

or

MEETS_STRONG_INTEGRITY

and for emulators only

MEETS_VIRTUAL_INTEGRITY

These 'fields' are all called via the Device Integrity API.

https://developer.android.com/google/play/integrity/verdict

😛 PW

PS. Just did this on 140 min flight from Broken Hill to Sydney... Just landed...
[Magisk] ipdev:
I am not sure about the Google Pay Magisk Discussion Thread but, posts (including mine) related to Play Integrity in the Universal SafetyNet Fix 2.3.1 thread seem to start around Post # 1,796.

All the posts about Play Integrity (that are not related to the USNF module) would have to be moved and kept in order to this thread.

I am not sure how easy that would be to do, since a lot of the discussion included linked posts in the responses.

Maybe @mrjuniork has an idea of the best and easiest way to do it?

Cheers. :cowboy:

PS.

Sorry to ping you mrjuniork.

I might be wrong but, it looks like you will be the one who gets stuck moving the posts. 🙃