Hi guys,
with reference to this interesting thread:
Strategic Alliance: bundle F-Droid, add LineageOS repository, add microG
I think that LineageOS may effectively be the reference Android ROM for people looking for privacy and timely updates (which implies more security).
In this view, it would be extremely convenient to have a working instance of microG on LineageOS, as it would add the convenience of gapps without the need to sell you soul to Google.
The only practical option to have a working instance of microG in CM/LineageOS is using an Xposed module which spoof the signature of microG. The alternative is recompiling CM/LineageOS from scratch by patching it "by hand" before. While viable, these two solutions are far from convenient, as the former depends on Xposed (which is not available for Nougat at the moment, and nobody can really tell if it will ever be) and the second... Well, in my understanding it requires a fair share of knowledge and also computing power and it is probably impractical from the point of view of view of the end user.
My question here is:
given that LineageOS will ship a separate ZIP to allow root to be enabled for apps, would it be technically possible for LineageOS developers to create (and ship ) also a separate zip to enable signature spoofing for people knowing what they are doing?
In my "vision" this could only add a permission that would have still to be manually enabled only for selected apps (microg, specifically).
In the end, only people really interested in microg would manually install the "spoofing" zip. And in this cases it would not pose any additional security risk (if you consider that enabling root may be already dangerous enough).
Let me emphatize that I don't know if this is technically feasible, nor if the developers would ever accept to do that. But in my opinion this should at least be discussed.
Thanks for reading and have a nice day!
E.
enban said:
Hi guys,
with reference to this interesting thread:
Strategic Alliance: bundle F-Droid, add LineageOS repository, add microG
I think that LineageOS may effectively be the reference Android ROM for people looking for privacy and timely updates (which implies more security).
Click to expand...
Click to collapse
I really really like this idea! It is important to give users an easy way to get rid of the intrusiveness of google, if they want to. It's a matter of freedom of choice.
More and more people are scared about (or simply don't like) mass collection of personal data, it would be nice if Lineage OS could give to these people an alternative!
enban said:
My question here is:
given that LineageOS will ship a separate ZIP to allow root to be enabled for apps, would it be technically possible for LineageOS developers to create (and ship ) also a separate zip to enable signature spoofing for people knowing what they are doing?
Click to expand...
Click to collapse
Or maybe a .zip that directly installs microG? (I don't know if it is possible...)
lamp1 said:
Or maybe a .zip that directly installs microG? (I don't know if it is possible...)
Click to expand...
Click to collapse
Installing microG is not a problem. Another user, @wdevil12 , already create an AROMA zip to install microG.
The problem is that microG NEEDS the signature spoofing to be available (it needs that so apps "think" that it is the "real" Google Play Services).
CM/LineageOS never wanted to build this option in the ROM, so one has to rely on Xposed or make one's own build by patching the sources.
Having a flashable zip enabling spoofing signature directly from LineageOS developers would be a huge leap forward and could impulse the use of microG (which, in my opinion, is the best thing happened to Android in years).
My 2 cents.
enban said:
Installing microG is not a problem. Another user, @wdevil12 , already create an AROMA zip to install microG.
The problem is that microG NEEDS the signature spoofing to be available (it needs that so apps "think" that it is the "real" Google Play Services).
Click to expand...
Click to collapse
Thank you for the explanation.
enban said:
Having a flashable zip enabling spoofing signature directly from LineageOS developers would be a huge leap forward and could impulse the use of microG (which, in my opinion, is the best thing happened to Android in years).
Click to expand...
Click to collapse
I agree with you!
+1
Is the lineage browser chromium based?
Is there a purge and replace google from android os tutorial somewhere?
micrograms without xposed
Hi,
I just wanted to share a link with you:
gabsoftware.com/tips/how-to-use-microg-on-lineageos-or-cyanogenmod-without-xposed
I haven't followed these steps yet, but am going to in a few days
enban said:
given that LineageOS will ship a separate ZIP to allow root to be enabled for apps, would it be technically possible for LineageOS developers to create (and ship ) also a separate zip to enable signature spoofing for people knowing what they are doing?
Click to expand...
Click to collapse
I share your enthusiasm and also your frustration.
Here's the thing. Enabling signature spoofing is a patch, so you apply it before building the image. This means a zip would have to provide a drop-in replacement for the files affected by the patch, in this case I believe it's only 1 file: framework.jar. I have no idea how often framework.jar changes, but it would be useful to know – the more often it changes, the more often the zip will have to be updated and distributed again, and the less probable it is that someone will want to do that job.
So here is an approach I was thinking of:
1. Extend the microG patch to not blindly disable signature spoofing, but instead disable it conditionally when a certain flag is enabled in the settings (disabled by default, obviously). Don't provide any UI, just that test in the code.
2. Include that patch in mainstream LineageOS (and other ROMs). By default it's a no-op, so that's completely harmless. This is the key point.
3. Provide a zip (OP's idea) that surfaces the modification of that flag through a "Disable signature spoofing" option in the Developer Settings.
Ideally, 3 would also be baked into mainstream LineageOS, since Developer Settings are already fairly opt-in. However, in light of what happened recently to root access, I'm assuming 3 would have to follow the same approach and live as an external zip too, which is fair enough and would still represent a huge step forward, as OP pointed out.
Thoughts?
Official answer:
We will not be enabling signature spoofing. It's a huge security hole, and breaking android's security model (for any reason) is never acceptable.
Feel free to build it yourself (it is open source) if this is a feature you want, or use one of the plethora of other roms people have generated. Our main goal is to continue passing CTS and have a production-shippable OS available for anyone who wants to use it.
@elirada
I like the idea and, frankly, I'm less concerned about the method to achieve it than on actually having signature spoofing.
Unluckily, as you can see, the official response is "No, never". Now, while I'm grateful to LineageOS developers for their hard work, I feel that their position on this point is plainly wrong. Allowing root is a bigger security issue than allowing on-demand signature spoofing for *one single* app, which would offer much more privacy to LineageOS users.
enban said:
@elirada
I like the idea and, frankly, I'm less concerned about the method to achieve it than on actually having signature spoofing.
Unluckily, as you can see, the official response is "No, never". Now, while I'm grateful to LineageOS developers for their hard work, I feel that their position on this point is plainly wrong. Allowing root is a bigger security issue than allowing on-demand signature spoofing for *one single* app, which would offer much more privacy to LineageOS users.
Click to expand...
Click to collapse
As zifnab said, we most certainly will not open up security holes like this. It would be an incredible disservice to our users.
Opening attack vectors such as this on millions of devices is "plainly wrong" as you put it.
But hey, its OSS, so fork and do it yourself! :good:
invisiblek said:
As zifnab said, we most certainly will not open up security holes like this. It would be an incredible disservice to our users.
Opening attack vectors such as this on millions of devices is "plainly wrong" as you put it.
But hey, its OSS, so fork and do it yourself! :good:
Click to expand...
Click to collapse
What disservice? You clearly didn't read the OP. One should voluntarily flash a zip and then explicitly enable the feature. It's not something that would happen by chance and would be an explicit choice of each user. And frankly, while I certainly may learn how to get the source and compile it, I (and most people willing to use microG) have not the hardware resources and the time to compile each build. To call this solution impractical would be an euphemism.
enban said:
What disservice? You clearly didn't read the OP. One should voluntarily flash a zip and then explicitly enable the feature. It's not something that would happen by chance and would be an explicit choice of each user. And frankly, while I certainly may learn how to get the source and compile it, I (and most people willing to use microG) have not the hardware resources and the time to compile each build. To call this solution impractical would be an euphemism.
Click to expand...
Click to collapse
Even if its something we'd remotely consider, its not as simple as providing a zip with a su binary in it like the root addon. This stuff is in framework which makes it a lot more difficult to supply a "bolt on" zip to do this.
Here's the patch when it was put on gerrit. You can read the comments to see the stance and reasoning on it.
It's something that will not ever be accepted in this project.
hey guys, thanks for this discussion.
i easily patched the first lineageos-build (kenzo device) with tingle. this was possible because "pre-optimization" wasnt yet enabled when built. patching took only 1 minute.
would it be possible to make any second build (or once a month) without this "pre optimization"-flag?
This way security isnt touched and everyone who wants could easily patch it himself!
We will not shipped compromised builds. It doesn't matter about how much you think it convenient...we are trusted to keep users safe.
The moment you have to use the words "spoof", "make the system think it's something else" or anything if that nature, you are lying to the system about an app, which will compromise thebuser's trust in the system.
If you think for one second that "experienced people who know what they are doing" would be the only ones to flash whatever the heck is available, you have not been on this forum or working with Android for very long.
If you "are experienced and know what you are doing", build it yourself. That's the safest bet against users not harming themselves with our stamp (release-keys) on it.
tl;dr: Nope. Not even once.
zifnab06 said:
Official answer:
We will not be enabling signature spoofing. It's a huge security hole, and breaking android's security model (for any reason) is never acceptable.
Feel free to build it yourself (it is open source) if this is a feature you want, or use one of the plethora of other roms people have generated. Our main goal is to continue passing CTS and have a production-shippable OS available for anyone who wants to use it.
Click to expand...
Click to collapse
Fair enough. Signature verification is clearly an important component of Android's security model.
I think one should never have to choose between security and convenience. Give users the choice for long enough and they'll end up falling for the latter. The minute someone provides a poorly crafted yet job-doing image, everybody will start using it. The "I won't solve your problem" answer, rather than help people, will end up pushing them into randomness.
As someone mentioned, maybe there would be a way to allow the overriding of signature checking only for a given app, in favor of another given app? This is very from just disabling the whole thing, yet would let microG work.
That idea is just an arbitrary suggestion. Generally my point is that people are expressing a use case to solve and if nobody cares they will end up doing something silly,
eli
Hi, I've finally manage to enable signature spoofing using tingle. The procedure is straightforward and very easy to follow (download script, make sure you have all needed programs, connect to rooted phone, execute the script, boom - done).
After that I was able to install microg and with Mozilla location backend it's working very well. So currently I'm running lineageos without gapps on oneplus 3t and can install apps from play store.
If any of you want I can write short instruction but all needed information can be found easily.
@alkesander
Is the patch only for LineageOS? Need patch for OxygenOS 4.0.3.
About the security implications of signature spoofing
zifnab06 said:
Official answer:
We will not be enabling signature spoofing. It's a huge security hole, and breaking android's security model (for any reason) is never acceptable.
Click to expand...
Click to collapse
I'm wondering why no one pointed to microG Signature Spoofing and its Security Implications before.
Interesting, glad I found this thread, that link, and the responses from CM/Lineage devs. Seems pretty clear that user privacy is not a priority, probably been the case since that Microsoft money started flowing in 2015..
Time to start looking elsewhere I guess
Related
I am having trouble finding decent instructions for getting the sources for a standard build for Motorola devices, specifically for athene.
I have built for Freescale products before and it usually involves some combination of repo init and patches, but that doesn't seem to be the case for Motorola.
I know the kernel and other sources are available on Github (https://github.com/MotorolaMobilityLL), but I don't see a manifest repository there. Nor can I find a device repo.
The closest thing to instructions I found was this readme (https://github.com/MotorolaMobilityLLC/readme/blob/master/MMI-MPJ24.139-23.4.txt) (xda wont let me post links, I'm too new a user here).
I am starting to suspect that Motorola is being as lazy as possible and only fulfilling the bare minimum of open source obligations, and thus doesn't provide a device repo, or manifest repo, etc.
Is that the case? I am new to running builds for standard phone manufacturers - are ROM developers around here forced to do legwork filling in what the manufacturers refuse to publish?
Or am I just missing the rest of the instructions from somewhere?
I have the same issue, did you ever manage to successfully complete a build? Thanks.
TheGreatCabbage said:
I have the same issue, did you ever manage to successfully complete a build? Thanks.
Click to expand...
Click to collapse
Nope, my impression of the situation remains the same, though I have not re-investigated. I would like if someone more knowledgeable confirmed though.
It is a shame, as I would really like a "known good" base to work off of and put in root support and remove unnecessary softwares in a legitimate way.
You *can* build LineageOS for athene: (https://wiki.lineageos.org/devices/athene/build)
I ran LineageOS for several months, but eventually switched back to stock. Has some strange issues in regards to texting (seems to only work when making a call).
Thanks for your reply. I've just managed to build Lineage OS for my device, and it seems to work ok.
I was previously using Resurrection Remix OS (which I didn't build, just downloaded a zip) and it worked very well, so if I have any issues with Lineage then I'll try to restore my TWRP backup of RR.
I wish I could use the AOSP codebase directly, though...
In this Article by Mishaal Rahman , we can understand why OnePlus and Nokia doesn't have treble support to their devices.
I open this thread to discuss about your opinions about how danger can be to create vendor partition outside system partition.
Tell us your opinion and how we can do it safely!
/vendor
FSadino said:
In this Article by Mishaal Rahman , we can understand why OnePlus and Nokia doesn't have treble support to their devices.
I open this thread to discuss about your opinions about how danger can be to create vendor partition outside system partition.
Tell us your opinion and how we can do it safely!
Click to expand...
Click to collapse
That partition is not accessible by the user or anyone else unless the phone is rooted, and it's no more dangerous than having the drivers and libraries in the system partition, OnePlus, as nothing more than a rebranded oppo, as well as Nokia, just don't want to put in the effort, Google has made it perfectly clear that treble is not optional, it is mandatory for devices shipping with Oreo and later, Nokia and OnePlus can do what they want with existing phones, but even they have no real choice that to support treble, unless of course that want to be stuck on phones shipping with nougat and maybe upgrading to Oreo, both of them will see the Android world passing them by and their implementations of Android will become more and more fragmented. Each to their own I suppose
Repartitioning a phone carries a certain risk, especially if it is done via OTA Update, but there are ways to do it and make it relatively safe...if you are willing to put in the work. I think that's the main point.
To me, it's much more interesting to see right now, how OEMs actually use Treble. They no longer have the excuses they used to, so someone like Sony should now be able to provide the Update to Android 8.1 within Days instead of Months...but will they actually do it?
The reasoning behind OnePlus deliberately not using Oreo on the 5T and not preplanning the extra partition...well, that tells it's own story. Not really that unexpected. Nokia though...I would have expected more from them, since they started with big promises about Stock Android and fast Updates, but so far very little has materialised...
I really think people are blowing this up far more then it needs to be. In the Google article it stated that even after the treble code is sent, the oems will still have to make their changes. So as far as I can see this will only matter to oems.
I expect to see many devices with day one 8.0 updates for a while.
Well, like I said, this will be the benchmark for Updates in the future. Since a new OS version can now boot on a phone without any big changes to the UI, Drivers or Apps, it SHOULD be far quicker. How much quicker will be interesting to see. Custom ROMs already show how fast the process can be...so... interesting times!
CommanderROR said:
Well, like I said, this will be the benchmark for Updates in the future. Since a new OS version can now boot on a phone without any big changes to the UI, Drivers or Apps, it SHOULD be far quicker. How much quicker will be interesting to see. Custom ROMs already show how fast the process can be...so... interesting times!
Click to expand...
Click to collapse
Yeah if you don't want any of the main features from the oem. Like Samsung cameras on aosp. Things like that.
As for faster updates. I doubt it. As now the oems will, have to do twice the work. Instead of adding their code to the stock frameworks. Now they will have to make completely new framework files to over write the default. Downloads will be a lot bigger now as well.
Hmm... that's not the way I understand Treble!
From what I've read, the OEM can basically exchange the OS Version without really touching much of their OEM UI...
The fact that Custom Roms are limited is mostly due to the fact, that devs don't have access to the OEM Sources, so they can only compile AOSP versions of Android...
CommanderROR said:
Hmm... that's not the way I understand Treble!
From what I've read, the OEM can basically exchange the OS Version without really touching much of their OEM UI...
The fact that Custom Roms are limited is mostly due to the fact, that devs don't have access to the OEM Sources, so they can only compile AOSP versions of Android...
Click to expand...
Click to collapse
And see that is why XDA articles are crap. The way OEMS roms have worked for years is that they replace and/or recode all of googles files. Now they will have to make even more. To over write them.
That is what you will get. Either AOSP or OEM. The aosp will not have access to the OEM code. Nor will OEM push their code to aosp for google to make things work right. This comes from the fact that OEMS dont write the drivers and code for alot of the hardware. They get that from others.
Just checked, my us997 LG G6 has a symlink for 'vendor', it points to 'system/vendor'... so no separate partition on the G6 either... I was hoping! alas.
Not unexpected...the G6 launched way before Treble was announced and hasn't been Updated to Oreo yet...
They should build a tool and require a wired connection to a pc to repartition and fallback just in case.
FWIW, I made patches to AOSP to be able to have a vendor partition WITHOUT needing to repartition, here:
https://github.com/phhusson/treble_experimentations/tree/master/no-vendor
The way it works, is it tells the kernel to look at the "system" partition, as if it was an hard-drive, to look for partition table, and then use partitions inside this fake hard-drive
Clever. Sell that idea to Oneplus and Nokia please...?
CommanderROR said:
Clever. Sell that idea to Oneplus and Nokia please...
Click to expand...
Click to collapse
I might be a good coder, but definitely not a good seller
phhusson said:
FWIW, I made patches to AOSP to be able to have a vendor partition WITHOUT needing to repartition, here:
https://github.com/phhusson/treble_experimentations/tree/master/no-vendor
The way it works, is it tells the kernel to look at the "system" partition, as if it was an hard-drive, to look for partition table, and then use partitions inside this fake hard-drive
Click to expand...
Click to collapse
Did you already tried this? I mean, I'm not developer and I can't understand the pros/cons about your patch but is extremely interesting!
@franciscofranco @eng.stk @Sultanxda @flar2 can you guys share your opinion about this? Thanks in advance
FSadino said:
Did you already tried this? I mean, I'm not developer and I can't understand the pros/cons about your patch but is extremely interesting!
Click to expand...
Click to collapse
Yup, actually my main testing device for my Treble ROM is a device using this.
Pros:
- doesn't need to repartition
- Easy to integrate
Cons are only for community rom devs:
- /system and /vendor are in read-only, even if dm-verity is disabled, the only way
- some TWRP change is required
- fastboot flashing will require to launch a s cript to merge system.img and vendor.img and flash both at the same time
Frankly, I'd guess OEMs had better to repartition. If you don't move partitions, only split system into system/vendor, and write the script with error-checking in mind, I really can't see how you would brick your device.
But this patch makes it possible to answer to OEMs saying they can't because of missing vendor partition
It will be interesting to see what happens, if a Device with strong XDA Community support like the OnePlus lineup can be "Trebleized" by the community and then supported more easily without help from the OEM that made it.
Following up here, very curious about where this is going.
Not a developer, but willing to test, my device is OP3T.
In light of a dev getting Treble support on the Redmi Note 4X, is it possible to get it on our devices too? I'm willing to test.
phhusson said:
FWIW, I made patches to AOSP to be able to have a vendor partition WITHOUT needing to repartition, here:
https://github.com/phhusson/treble_experimentations/tree/master/no-vendor
The way it works, is it tells the kernel to look at the "system" partition, as if it was an hard-drive, to look for partition table, and then use partitions inside this fake hard-drive
Click to expand...
Click to collapse
Does the Zenfone 4 use your patch actually? (didn't checked if sources are available yet)
I read a while back that first devices (or just one device?) is now project treble ready without vendor partition, not knowing you might have anything to do with it...
For reference:
https://www.androidpolice.com/2017/11/26/phones-updated-support-project-treble-continuously-updated/
Sent from my OnePlus 3T using XDA Labs
(18-08-2018)
Recently we've been hearing a lot of theories about
1) miss titled treble ROMs.
2) vendor partition vs vendor interfaces.
3) security risks of having a separate vendor partition.
Can knowledgeable persons share your honest views and help me and many other newbies understand this!????
Some useful stuff which would help this topic:
(19-08-2018)
1) we can enable treble without a separate vendor partition.
Source: https://www.xda-developers.com/asus-zenfone-4-android-oreo-project-treble/
(08-09-18)
2)On non-treble roms, vendor libs are located at /system/vendor/. System partition is available to system apps only. There is a special platform signature that is generated during the build, so that only apps signed with it have access to system partition. There is no such thing for a separate vendor partition. Especially on our Zuk, they just renamed factory partition to vendor and moved all vendor libs (the ones responsible for camera, gps, wifi, etc) from system/vendor to /vendor. Vendor is not protected by Android signature. It is wide open for read/write/execution, otherwise hardware won't work. Android provides for VNDK, which addresses this security issues, but in our zuk, it is broken (you get warnings during the build that vndk is broken). So, right know, any treble rom for our Zuk has vendor partition open and any app (not just system), can grab a vendor lib and have access to hardware. In addition, any app can write to that partition without any root rights.
(info from optimumpro)
Bharath A said:
Recently we've been hearing a lot of theories about
1) miss titled treble ROMs.
2) vendor partition vs vendor interfaces.
3) security risks of having a separate vendor partition.
Can knowledgeable persons share your honest views and help me and many other newbies understand this!????
Click to expand...
Click to collapse
Ok
How would it be a security risk by just moving vendor folder to separate partition????
Read google's documentation fully, else you will end up with half knowledge like optimum and just make unwanted threads on xda leading to unwanted things.
https://source.android.com/devices/architecture/
And you yourself find the answer to the questions u have
---------- Post added at 11:22 AM ---------- Previous post was at 11:22 AM ----------
dvssvar said:
How would it be a security risk by just moving vendor folder to separate partition????
Click to expand...
Click to collapse
There isnt one. Else google aint fool to promote treble lol
Hello,
I am not a dev so even after reading benefits of treble, I may not be able to understand the whole point. As an average user, what I understand is that, treble is the way forward, and for Android P, all ROMs and their devs are switching to Treble.
Thinking about why I have stayed away from non treble ROMs ever since introduction of treble. I can clearly see the performance advantage a non treble ROM in general has over a Treble. But Pie is out, and so is the first Pie based ROM for Z2 Plus. Surprisingly it is a non treble.
I am like WHAT?
If Devs don't need Treble for Pie and device is running better (in general) with non Treble, as an general user, what is there for me with Treble. I am left wondering with that thought !!
Sorry for being Dumb here. Bit frustrated to with myself as misunderstood the Treble as way forward and kept my self away from non Treble ROMs.
Thanks.
amog787 said:
Read google's documentation fully, else you will end up with half knowledge like optimum and just make unwanted threads on xda leading to unwanted things.
https://source.android.com/devices/architecture/
And you yourself find the answer to the questions u have
---------- Post added at 11:22 AM ---------- Previous post was at 11:22 AM ----------
There isnt one. Else google aint fool to promote treble lol
Click to expand...
Click to collapse
Meaning that very less changes needed in trees for treble ROMs? Like does it mean that Oreo trees can boot P?
Sent from my ZUK Z2 Plus using XDA Labs
If you want treble and security perfect , go and get a pixel mobile and have fun flashing all gsi images XD
dvssvar said:
How would it be a security risk by just moving vendor folder to separate partition????
Click to expand...
Click to collapse
Because libs in a separate vendor partition, the way it is done in so called treble roms for our Zuk, are open to third party apps, which can take over the phone by hijacking those libs. Vendor libs in /system/vendor/, on the other hand, are fully protected.
amog787 said:
Read google's documentation fully, else you will end up with half knowledge like optimum and just make unwanted threads on xda leading to unwanted things.
https://source.android.com/devices/architecture/
And you yourself find the answer to the questions u have
---------- Post added at 11:22 AM ---------- Previous post was at 11:22 AM ----------
There isnt one. Else google aint fool to promote treble lol
Click to expand...
Click to collapse
You are confusing a separate Vendor partition, which has nothing to do with treble, and Vendor intarface - HIDL, which IS treble.
I have nothing against real treble, and Google certainly ain't fool, and by the way, they don't require a separate vendor partition, just a proper implementation of HIDL. Also, Google provides additional protection - VNDK, which again, doesn't properly function on our Z2.
So, as a result, no custom rom (for our zuk) that calls itself treble, is any more treble, than any non treble custom rom. The only difference is that such 'treble' roms have a separate vendor partition with fully hackable libs.
Treble is nothing but just vendor partition which contains mostly all device specific files so with the seperate vendor image and partition it will get easy for users and developers to provide updates
Users can wipe their system partition (which contains ROM specific stuff like framework,apps,etc) so with treble users can enjoy different system images without need of flashing whole new ROMs.
It is specifically made for ease of OEM when manufacturer makes new update if update only contain system specific improvements they can only give users only system image rather than full build.
The issue without treble is that device specific files and system specific files are stored at different location rather than at separate place treble makes it easy with differentiating device specific files and system specific files.
And it is ofc secure vendor partition have their vendor sepolicy to take care of security.
Apps with root access can create problem if purposely made for hacking
info from optimumpro
"On non-treble roms, vendor libs are located at /system/vendor/. System partition is available to system apps only. There is a special platform signature that generated during the build, so that only apps signed with it have access to system partition. There is no such thing for a separate vendor partition. Especially on our Zuk, they just renamed factory partition to vendor and moved all vendor libs (the ones responsible for camera, gps, wifi, etc) from system/vendor to /vendor. Vendor is not protected by Android signature. It is wide open for read/write/execution, otherwise hardware won't work. Android provides for VNDK, which addresses this security issues, but in our zuk, it is broken (you get warnings during the build that vndk is broken). So, right know, any treble rom for our Zuk has vendor partition open and any app (not just system), can grab a vendor lib and have access to hardware. In addition, any app can write to that partition without any root rights."
optimumpro said:
So, as a result, no custom rom (for our zuk) that calls itself treble, is any more treble, than any non treble custom rom. The only difference is that such 'treble' roms have a separate vendor partition with fully hackable libs.
Click to expand...
Click to collapse
But it enables the ability to use GSI images, doesn't it? At least it's more "treble" than non-treble ROMs at that
pipyakas said:
But it enables the ability to use GSI images, doesn't it? At least it's more "treble" than non-treble ROMs at that
Click to expand...
Click to collapse
Yes, but GSI is vanilla android. So, if you use GSI, you'll be stuck with that. No major custom rom does GSI. They build the regular way. And by the way, there is a number of regularly built vanilla android P available for our zuk, so there is no need for GSI.
Also, even with HIDL interface, one has to be careful, as hidl libs are by definition general ones (or taken from another device), as opposed to OEM made specifically for your device. And when you convert everything to HIDL with those non-device specific blobs, you get performance impairment that many users complain about on treble roms.
Edit: Again, I am not against treble, but it has to be properly done: example - I have switched to Oneplus 5, and in their August firmware update (which so far they have been doing monthly), they have switched to treble with a separate vendor partition. That means that in addition to separate vendor, they also have a working VNDK + all hidl libs specifically made for Oneplus 5. So, custom rom devs can take and use those latest blobs, and have no performance degradation in their builds.
optimumpro said:
Yes, but GSI is vanilla android. So, if you use GSI, you'll be stuck with that. No major custom rom does GSI. They build the regular way. And by the way, there is a number of regularly built vanilla android P available for our zuk, so there is no need for GSI.
Also, even with HIDL interface, one has to be careful, as hidl libs are by definition general ones (or taken from another device), as opposed to OEM made specifically for your device. And when you convert everything to HIDL with those non-device specific blobs, you get performance impairment that many users complain about on treble roms.
Edit: Again, I am not against treble, but it has to be properly done: example - I have switched to Oneplus 5, and in their August firmware update (which so far they have been doing monthly), they have switched to treble with a separate vendor partition. That means that in addition to separate vendor, they also have a working VNDK + all hidl libs specifically made for Oneplus 5. So, custom rom devs can take and use those latest blobs, and have no performance degradation in their builds.
Click to expand...
Click to collapse
Thanks for the info
Is it like only OEM's could implement VNDK, or can it be done by any dev.
Is it same for all phones which doesn't have treble implemented by OEM's??
chimpu10 said:
Thanks for the info
Is it like only OEM's could implement VNDK, or can it be done by any dev.
Is it same for all phones which doesn't have treble implemented by OEM's??
Click to expand...
Click to collapse
If OEM does it, then it's for sure good. Otherwise, I don't know. You really have to build to see, if there are no warning messages about VNDK, then you should be OK. See, you can't set vendor partition to non-executable straight, because hardware won't work. So, it has to be open, but requests must go through VNDK (which has restrictions).
Oh well ... I think some of you enjoys the moderator`s presence more than anything .. anyway, off topic posts removed and you guys knows who you are , I`m not going to say it again, keep it civil and constructive here on XDA
thanks for understanding
Dan - forum moderator
In any custom rom, if the Google play store shows that "Device is certified" then is that particular rom has support of "VNDK Security" ?
Isaacjohn said:
In any custom rom, if the Google play store shows that "Device is certified" then is that particular rom has support of "VNDK Security" ?
Click to expand...
Click to collapse
Are you talking about play protect!!!?????
If yes, it checks for harmful apps, regularly check behavior of apps... And as of my knowledge it has nothing to do with 'VNDK Security'
Isaacjohn said:
In any custom rom, if the Google play store shows that "Device is certified" then is that particular rom has support of "VNDK Security" ?
Click to expand...
Click to collapse
LoL
Damn dude
I recently got a 6P and have learnt a few things that are pushing me towards a custom ROM;
1. No Night Light (blue light filter) on stock.
2. No NFC quick toggle
3. Enforced encryption
4. In the event of the dreaded bootloop, I understand it's only possible to rescue the device if bootloader is unlocked.
I don't particularly want to unlock the bootloader etc as I want to be able to use Google Pay and banking apps freely, however I understand that with the use of Magisk this shouldn't be a problem.
I've rooted etc many devices since Android 2 but I'm aware that each device has its quirks.
Basically (TLDR):
What do I need to know/do to get from Stock to ABC rom with with Google Pay etc working fully?
Thanks for your help!
Just found this thread:
https://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Is all of that still accurate? Anything else on top of that worth knowing?
tooplanx said:
Just found this thread:
https://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Is all of that still accurate? Anything else on top of that worth knowing?
Click to expand...
Click to collapse
As far as flashing 8.1 devices? Yeah, based on when this device was made the unlock and flash process was nice and simple.
Don't be surprised if some stuff won't work with an unlocked BL though. Yeah root can hide itself but some safety net checks are better than others and they look at the BL. I don't use banking apps on an unsafe phone, but I still see people every once in a while posting about *whatever* app they use does not work due to safety net.
Do not use above as a reason to lock your BL on a custom rom. NEVER do it.
If you descide at some point to want to move on to 9.0, do some research between FDE encryption, which is what this device has always used. And FBE encryption which some people are building 9.0 ROMs with. This will save you from me yelling at you for not being able to read an OP if you want to go to 9.0
Thanks for your reply.
I apologise for being lazy in my post. I have two small children and know from part experience that one can spend a long time collecting various patchy, out dated pieces of info from disparate, incomplete forum threads! However, it seems that there is pretty good, comprehensive tutorials for the Nexus 6p :victory:
My main questions I guess now are:
1. Do I still need to flash the vendor image if coming from stock 8.1?
2. I've heard ABC has safetynet built in... Does this mean Google Pay etc is more likely to work?
3. I can't find a link to the last ABC rom. That Kajinsk(?) Website doesn't seem to be in use anymore.
4. Is it possible to go back to fully stock with a locked bootloader if I decide to?
Thanks
tooplanx said:
Thanks for your reply.
I apologise for being lazy in my post. I have two small children and know from part experience that one can spend a long time collecting various patchy, out dated pieces of info from disparate, incomplete forum threads! However, it seems that there is pretty good, comprehensive tutorials for the Nexus 6p :victory:
My main questions I guess now are:
1. Do I still need to flash the vendor image if coming from stock 8.1?
2. I've heard ABC has safetynet built in... Does this mean Google Pay etc is more likely to work?
3. I can't find a link to the last ABC rom. That Kajinsk(?) Website doesn't seem to be in use anymore.
4. Is it possible to go back to fully stock with a locked bootloader if I decide to?
Thanks
Click to expand...
Click to collapse
If the vendor image does not match the month of the rooms security patch you get a message that pops up on the device about it, other than that I doesn't hurt anything.
No idea, again, I don't mess with stuff that checks safteynet.
Not sure on the rok quest either, can try in the thread but yeah kantjer nuked his site when he got rid of his 6p.
Yeah, just get the factory image from the Google site and fastboot flash it.
Lawlrus said:
If the vendor image does not match the month of the rooms security patch you get a message that pops up on the device about it, other than that I doesn't hurt anything.
Click to expand...
Click to collapse
Even if vendor image is newer than rom security patch? So I'd probably have to flash an older vendor image than the current OPM7.181205 so that it matches whatever the last ABC rom patch level was?
Knowing that I can go back to stock and locked bootloader makes me happier to see how things go with a custom rom. I know some devices can't be relocked fully.
Think I've found the last ABC rom image:
https://androidfilehost.com/?w=files&flid=288070
tooplanx said:
Even if vendor image is newer than rom security patch? So I'd probably have to flash an older vendor image than the current OPM7.181205 so that it matches whatever the last ABC rom patch level was?
Knowing that I can go back to stock and locked bootloader makes me happier to see how things go with a custom rom. I know some devices can't be relocked fully.
Think I've found the last ABC rom image:
https://androidfilehost.com/?w=files&flid=288070
Click to expand...
Click to collapse
As I said, I have NEVER heard of anyone having issues not being on the right vendor aside from a notification on reboot.
Okay, thanks!
I just bought an S5E, and having owned two previous Samsung devices, I expected a fair amount of bloat, but not nearly the amount I discovered. It makes my previous two Samsungs look downright slender. Particularly loathsome, in my view, is the way SS has hijacked Find My Mobile and Google Messages, the latter of which, as a Google Fi customer, I have to use for SMS.
Hence, I am going to root, and cleanse this otherwise delightful device with the fire of 1000 suns. I have rooted Android devices before, but it's been a while, and my memory hasn't improved with age, so I have several questions, some about rooting in general, and some specific to this device. I should add that, while I am not opposed to performance gains and newer versions of Android and suchlike, my only pressing concern is to de-Samsungize the bejeebers out of this thing. Other than that, something like a stock version of Android and an otherwise low-maintenance tablet will make me very happy. So, here goes:
I have the PewPewk method bookmarked, and believe I have one or two others using various combinations of ADB and Magisk and suchlike bookmarked. I imagine I can handle them, but they look complicated. Are any of the apparently simpler approaches found here effective, sufficient to achieve my goals, and unlikely to brick me?
What are the advantages of Custom Android Recoveries relative to the stock Android, and if they add much in the way of complications, can I live without them?
Do I need a custom ROM, and more specifically, do I need one to give me non-Samsungized versions of Find My Mobile and Google Messages? At a minimum, I need the garden-variety version of Google Messages so I can text like a normal person, not a Samsung zombie.
Again, I don't really need tweaks for performance or new versions of Android, but I do need to get bug fixes and security patches with a minimum of fuss. How do I find that minimal sweet spot?
If the answers to one or more of these question are that yes, I need a custom recovery and/or ROM - I suspect this will be the case - then can anyone recommend good candidates that will get me the outcomes I'm looking for without perplexing me too greatly and making me want to cuss?
Can anyone identify the questions which I should be asking, but which didn't occur to me, and then pose them and answer them?
I'm confident that I'm in the right forum to get the answers I need, so all advice will be greatly appreciated.
smilejack1 said:
I just bought an S5E, and having owned two previous Samsung devices, I expected a fair amount of bloat, but not nearly the amount I discovered. It makes my previous two Samsungs look downright slender. Particularly loathsome, in my view, is the way SS has hijacked Find My Mobile and Google Messages, the latter of which, as a Google Fi customer, I have to use for SMS.
Hence, I am going to root, and cleanse this otherwise delightful device with the fire of 1000 suns. I have rooted Android devices before, but it's been a while, and my memory hasn't improved with age, so I have several questions, some about rooting in general, and some specific to this device. I should add that, while I am not opposed to performance gains and newer versions of Android and suchlike, my only pressing concern is to de-Samsungize the bejeebers out of this thing. Other than that, something like a stock version of Android and an otherwise low-maintenance tablet will make me very happy. So, here goes:
I have the PewPewk method bookmarked, and believe I have one or two others using various combinations of ADB and Magisk and suchlike bookmarked. I imagine I can handle them, but they look complicated. Are any of the apparently simpler approaches found here effective, sufficient to achieve my goals, and unlikely to brick me?
What are the advantages of Custom Android Recoveries relative to the stock Android, and if they add much in the way of complications, can I live without them?
Do I need a custom ROM, and more specifically, do I need one to give me non-Samsungized versions of Find My Mobile and Google Messages? At a minimum, I need the garden-variety version of Google Messages so I can text like a normal person, not a Samsung zombie.
Again, I don't really need tweaks for performance or new versions of Android, but I do need to get bug fixes and security patches with a minimum of fuss. How do I find that minimal sweet spot?
If the answers to one or more of these question are that yes, I need a custom recovery and/or ROM - I suspect this will be the case - then can anyone recommend good candidates that will get me the outcomes I'm looking for without perplexing me too greatly and making me want to cuss?
Can anyone identify the questions which I should be asking, but which didn't occur to me, and then pose them and answer them?
I'm confident that I'm in the right forum to get the answers I need, so all advice will be greatly appreciated.
Click to expand...
Click to collapse
Hello there
Your questions are really deep, maybe that is why no answers so far
I'm not an expert at all, so I can't give you comprehensive answers. But I rooted Tab S5e successfully (on stock ROM) and I've read a lot about modifying it, so I can share just few hints.
I wouldn't bother of any other rooting method than Magisk. However, this tab isn't as easy to root as most of the other devices... By far the best and comprehensive guide to root the stock ROM is here:
Galaxy Tab S5e (SM-T720) - Root Instructions (Release 1.0) | XDA Developers Forums (xda-developers.com)
If you follow it closely, you shouldn't have problems. I did it and can confirm it's working fine.
I haven't used custom ROM on this device, but there are some available, especially LineageOS from the recognized developer and one of the LineageOS team member. You can take a look on those threads:
[ROM][OFFICIAL][gts4lvwifi][10] LineageOS 17.1 | XDA Developers Forums (xda-developers.com)
[ROM][UNOFFICIAL][gts4lvwifi][11] LineageOS 18.1 | XDA Developers Forums (xda-developers.com)
In order to flash custom ROM you need custom recovery. There is TWRP available:
Samsung Galaxy Tab S5e WiFi (twrp.me)
Again, I did not try to flash it, I've heard it's tricky, so you need to dig dipper inside those threads and articles.
Alternatively, there is a method to debloat stock ROM without root. It is described in this thread:
[Guide] Samsung Galaxy Tab S5e Debloat Without Root-Info | XDA Developers Forums (xda-developers.com)
Hope it helps!
Thank you for your input. By the time you offered it, I had plunged ahead with the rooting method you suggested. Overall, it went well, but I'm having a few issues with the tablet since getting Lineage 17.1 installed.
I have made a new post requesting help with those issues, which can be found here. If you can offer any advice thereupon, I would be greatly appreciative, and if not, thank you for your efforts above.