Related
So, I've looked at every vendor tree that I can find. Not all of them are set up the same, but that appears to be taken care of via the .mk files. I really want to help some folks with an Eris vendor tree. Is there anyone out there who can and will explain a few things to me?
1) What proprietary files can we leave in the repo, if any? I've seen at least one repo that seems to have some proprietary binaries in it, but then uses the extract-files.sh to pull the rest. I just don't get where the line is. Maybe they don't either?
2) Why can't we put all of the proprietary files in the repo? If we're building the ROM, and we're just going to put them on the ROM and post it anyway...
(I get copyright issues, but posting them in the ROM and posting them in the repo seem to be pretty much the same to me. )
Thanks!
I would like to know the same thing.
I would also like to see a detailed "map" of the files in a "generic" rom
I have tried making sense of them by looking inside, but I am having a hard time telling if the files I am seeing are generic Android, device specific, or extra files someone threw in to customize the rom
I think a good start would be a list of the minimum files required to get Android running on a device along with a description of what each file (or at least each group of files) does.
Then maybe later add a description of the optional packages.
ROM chefs could then use that list as a starting place and add the specific information for the device they are cooking for.
Anyone know of a list like this or maybe one that is at least partially complete so that we wouldn't have to start from scratch?
Ok I am trying to build a Torch APK from git sources from Wayland_Ace. I went to repository and downloaded them as a zip. I've set up ADT and have Eclipse running. I chose to create a project with existing sources and chose the folder I extracted from the zip.
Now, I want to make some edits to this and I already know how and what I am going to, but I figured I would make sure the app would build before I made any changes and it won't. I get four "TORCH_STATE cannot be resolved or is not a field" errors and few warnings about some imports never being used.
I have a feeling this is because it's importing the settings from stock Android and not CM10.1. Can anyone help me fix this so I can build a Torch APK. I've Googled and fooled around with this for hours and have not had any success and am getting a bit frustrated.
admiralspeedy said:
Ok I am trying to build a Torch APK from git sources from Wayland_Ace. I went to repository and downloaded them as a zip. I've set up ADT and have Eclipse running. I chose to create a project with existing sources and chose the folder I extracted from the zip.
Now, I want to make some edits to this and I already know how and what I am going to, but I figured I would make sure the app would build before I made any changes and it won't. I get four "TORCH_STATE cannot be resolved or is not a field" errors and few warnings about some imports never being used.
I have a feeling this is because it's importing the settings from stock Android and not CM10.1. Can anyone help me fix this so I can build a Torch APK. I've Googled and fooled around with this for hours and have not had any success and am getting a bit frustrated.
Click to expand...
Click to collapse
How are you trying to build the apk? Through eclipse or through the android sdk?
fairct said:
How are you trying to build the apk? Through eclipse or through the android sdk?
Click to expand...
Click to collapse
Eclipse.
admiralspeedy said:
Eclipse.
Click to expand...
Click to collapse
I took a look at the source (CMs, not the one you pulled), and it is indeed because you don't have the CM SettingsProvider. It may sound foolish, and I'm not sure what will happen, but you could try commenting it out. I think that's just updating a system var so that things like the power widget can update appropriately. Worst case scenario you get a force-quit, or your LED won't turn off, forcing a battery pull
fairct said:
I took a look at the source (CMs, not the one you pulled), and it is indeed because you don't have the CM SettingsProvider. It may sound foolish, and I'm not sure what will happen, but you could try commenting it out. I think that's just updating a system var so that things like the power widget can update appropriately. Worst case scenario you get a force-quit, or your LED won't turn off, forcing a battery pull
Click to expand...
Click to collapse
I'm not going to do that, however your answer is extremely helpful now that I know it's caused by settings provider. Do you know how I could use a different settings provider in Eclipse? I could take the CM10.1 from the git of the ROM I'm using and somehow use it in Eclipse.
I really find it strange that I can only find a couple other people asking the same question as I. Do people not edit a single app from Cyanogenmod or some other ROM like AOKP without rebuilding the entire source? Upon doing some more Googling, it seems I need an Android.jar from Cyanogenmod.
Hoew I get this, I'm not sure.
admiralspeedy said:
I really find it strange that I can only find a couple other people asking the same question as I. Do people not edit a single app from Cyanogenmod or some other ROM like AOKP without rebuilding the entire source? Upon doing some more Googling, it seems I need an Android.jar from Cyanogenmod.
Hoew I get this, I'm not sure.
Click to expand...
Click to collapse
Well, I think they generally pull whatever APK they want, and then modify it to make it work. In some instances, that means changing other apks due to interdependency. Maybe someone who's familiar with building in eclipse could point you in a better direction...
I did it. I followed a guide to build a custom Android.jar from my phones framework.jar and Eclipse wouldn't build after because of it, so instead I only replaced the class files for settingprovider and my app had no errors after. I then saved the class files I edited, decompiled the classes.dex from the existing Torch APK and replaced the classes in it with my edited ones, recompiled that into a new classes.dex and put that in the Torch APK and it worked!
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!
First off, before I get into it; nay sayers and trolls please keep the thread clear. Hopefully we can figure something and more minds together normally equal victory.
Last night an idea hit me, I use a hack with Windows that allows admin permissions and I don't have enough info about android apks to say that it wont work.
In Windows (yes I know they are way different) if you can figure a way to temp change one sys program to be command prompt, you can add users, change admin passwords, delete logs and the such. Basically you own the box at that point. Im not going to go into the details cause as far as I know M $ hasnt fixed it and I dont want them to.
So if we can find an apk with root writing permissions and can change it to be a term emulator we should be able to chmod root.
I have made some attempts, using the hidden menu apk. I figure it can change the prop file it should have root privileges; with no luck. Maybe I am not repackaging the apk correctly or something?
If someone that knows more about apks thinks it may be a possibility lets get to cooking!
The Command Prompt trick you're talking about is very well known. It's been around since Vista and has yet to be patched and unlikely to be due to the nature of how it works.
Thanks Pirate, I know what versions it works with. But I guess no one knows how we can possibly accomplish the same in android.
Zer0C0oL said:
Thanks Pirate, I know what versions it works with. But I guess no one knows how we can possibly accomplish the same in android.
Click to expand...
Click to collapse
If you did, wouldn't you end up in a bootloop due to dm-verity, or is this not modifying /system?
Lifehags said:
If you did, wouldn't you end up in a bootloop due to dm-verity, or is this not modifying /system?
Click to expand...
Click to collapse
The way I understand the DMVerity mechanism is it rebuilds its trust chain every time a legitimate system change is made. When you perform a PRL update, the app makes a change to the system. This does not equal bootloops and I believe we can accomplish the same via this hack, if apk permissions can be loaned.
In the M$ hack you can't leave the change in place as it messes up other processes. Basically you use it to add a user with admin permissions/ open a backdoor and then cover your tracks: which one step is reverting the swap so there are no system issues for the users to find.
Alas, I fear the people this post should be reaching are the ones working towards claiming the bounty and for that reason collaboration will be non-existent.
@Zer0C0oL, please note that unless you are a developer working on a recovery, ROM or a Kernel, you should not be posting the development section. Please refer to this announcement if you have any questions.
I've moved this thread to the How-To section where it belongs.
Cheers :good:
Zer0C0oL said:
First off, before I get into it; nay sayers and trolls please keep the thread clear. Hopefully we can figure something and more minds together normally equal victory.
Last night an idea hit me, I use a hack with Windows that allows admin permissions and I don't have enough info about android apks to say that it wont work.
In Windows (yes I know they are way different) if you can figure a way to temp change one sys program to be command prompt, you can add users, change admin passwords, delete logs and the such. Basically you own the box at that point. Im not going to go into the details cause as far as I know M $ hasnt fixed it and I dont want them to.
So if we can find an apk with root writing permissions and can change it to be a term emulator we should be able to chmod root.
I have made some attempts, using the hidden menu apk. I figure it can change the prop file it should have root privileges; with no luck. Maybe I am not repackaging the apk correctly or something?
If someone that knows more about apks thinks it may be a possibility lets get to cooking!
Click to expand...
Click to collapse
I'm pretty sure it may be possible however impossible to avoid tripping knox.
"Blobs" are the files specific to each device that we need in order to compile custom ROMS that work on our device. The process of finding them is tedious and slow... I have been picking away at them for months when I have time. There are over 600 files so far! But there are also references to files that are not being found. They are either missing, or they are not located where they are expected to be located. This is where I need help.
So, if you want to help, go HERE:
https://github.com/mightysween/android_vendor_motorola_payton
and look through the proprietary-files.txt file for anywhere that it says "warning".... and then search inside of the firmware (working on 8.0+ now, not 7.1 please) and try to track down the file that it says is missing [obviously, you will need a system dump, or to search on a rooted device]. If you find it, please post below like this:
LINE NUMBER OF THE WARNING (from github)
PATH TO THE MISSING FILE (relative to /system... in other words, don't inlude your own local path)
Once this file is complete, we can use it to automatically pull the correct vendor files into our build environments... having a working recovery, active kernel developement and completed vendor blobs should open us up to more development efforts.
Also, if anyone has done any testing and knows of other proproetary files that are needed, please post them here so I can include them.
My time at the computer to work on this is really limited, so I have only identified a dozen or so daemons that definitely call for proprietary libs... I am sure there are more
I would love to pitch in on this but have zero experience with anything related to development. Do you think I could still be of help? Sounds like a basic enough task that it wouldn't be too difficult. Let me check and see that I understand the process.
Went to github and looked at proprietary-files.txt. The first warning I found was in line 49: "blob file libpn553_fw.so missing or broken". Then searched for that file in my device's system folder using ES File Explorer with Root Explorer enabled.
So is this what you're looking for?
49
/system/vendor/firmware/libpn553_fw.so
---------- Post added at 14:31 ---------- Previous post was at 14:07 ----------
I'd like to contribute in some way but if this is best not left to a complete noob then I totally understand
mightysween said:
Also, if anyone has done any testing and knows of other proproetary files that are needed, please post them here so I can include them.
My time at the computer to work on this is really limited, so I have only identified a dozen or so daemons that definitely call for proprietary libs... I am sure there are more
Click to expand...
Click to collapse
Do you have a link to a system dump?
TheBassDude said:
I would love to pitch in on this but have zero experience with anything related to development. Do you think I could still be of help? Sounds like a basic enough task that it wouldn't be too difficult. Let me check and see that I understand the process.
Went to github and looked at proprietary-files.txt. The first warning I found was in line 49: "blob file libpn553_fw.so missing or broken". Then searched for that file in my device's system folder using ES File Explorer with Root Explorer enabled.
So is this what you're looking for?
49
/system/vendor/firmware/libpn553_fw.so
---------- Post added at 14:31 ---------- Previous post was at 14:07 ----------
I'd like to contribute in some way but if this is best not left to a complete noob then I totally understand
Click to expand...
Click to collapse
Thanks, that is all there is to it
Just time consuming (especially after the first 500)...lol
QWZR said:
Do you have a link to a system dump?
Click to expand...
Click to collapse
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
mightysween said:
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
Click to expand...
Click to collapse
Mine gets here next week
mightysween said:
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
Click to expand...
Click to collapse
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
ebrandsberg said:
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
Click to expand...
Click to collapse
Any way that works is fine by me
I am on the road a lot and just don't have enough time to sit and work on it... so it is taking months. I bet a few people helping could finish it in a matter of hours.
I am hoping to have a few hours next week to work on it. But the sooner this is done, the sooner I can shift to trying to compile Lineage OS with working hardware.
BTW, Lineage *does* compile if I comment out all the stuff causing make errors... not much works, obviously.
The next step will be compiling with these blobs, then logging all the new errors and chasing down all the additional broken symlinks... and then adapting the kernel as needed.
Then, MAYBE we can get a base Lineage tree up and open up the X4 to building for other roms. I know someone started a skeleton tree for Carbon already on Github... they are likely just waiting for the completed device tree, too.
mightysween said:
Thanks, that is all there is to it
Just time consuming (especially after the first 500)...lol
Click to expand...
Click to collapse
ebrandsberg said:
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
Click to expand...
Click to collapse
I don't own this device yet, but I was thinking of getting one. I figured this might help you all out (you'll need to be running linux):
First, let's get a list of all the files on the phone, to make searching faster.
Code:
adb shell
su
find / > /sdcard/allfiles.txt
exit
exit
adb pull /sdcard/allfiles.txt
Now you should have allfiles.txt on your machine. Also grab the proprietary-files.txt, and then run this:
Code:
grep -Po '(?<=(blob file )).*(?= missing or broken)' proprietary-files.txt | xargs -I @ grep "@" allfiles.txt
That should find the paths of all the missing files (except the ones marked "wildcard")
BLuFeNiX said:
I don't own this device yet, but I was thinking of getting one. I figured this might help you all out (you'll need to be running linux):
First, let's get a list of all the files on the phone, to make searching faster.
Code:
adb shell
su
find / > /sdcard/allfiles.txt
exit
exit
adb pull /sdcard/allfiles.txt
Now you should have allfiles.txt on your machine. Also grab the proprietary-files.txt, and then run this:
Code:
grep -Po '(?<=(blob file )).*(?= missing or broken)' proprietary-files.txt | xargs -I @ grep "@" allfiles.txt
That should find the paths of all the missing files (except the ones marked "wildcard")
Click to expand...
Click to collapse
Thanks, I had recently completed this, but your code worked fantastic for double checking, and actually helped me find one that I had missed :good:
Now, on to identifying any more daemons that need proprietary files... and then assembling the tree itself... PROGRESS!
PHASE 1 is complete!
https://github.com/mightysween/android_vendor_motorola_payton
I am 99% sure that this is only ~75% of what will be needed to actually build LOS15. But it is a good foundation to work off of now.
My plan is to start attempting to compile LOS and take error logs to chase down the remaning missing stuff. LOTS to be done still to get to that point...hoping for some other builders/devs to materialize here and help out
Hi! Just a question: it´s mandatory to use A/B partition scheme to build a custom ROM for this device or it will be possible to use a traditional partition scheme and free up some GBs of internal storage for use?
christianrj said:
Hi! Just a question: it´s mandatory to use A/B partition scheme to build a custom ROM for this device or it will be possible to use a traditional partition scheme and free up some GBs of internal storage for use?
Click to expand...
Click to collapse
It would seem that we will still be stuck with A/B, as the bootloader does the initial check of the active slot. Perhaps there may be some clever ways around this in the future...but nothing I will be tackling.
mightysween said:
It would seem that we will still be stuck with A/B, as the bootloader does the initial check of the active slot. Perhaps there may be some clever ways around this in the future...but nothing I will be tackling.
Click to expand...
Click to collapse
You would probably need a custom kernel to do it properly. The bootloader passes a kernel param (androidboot.ro.boot.slot_suffix) specifying which slot to use. In the absense of a kernel param, the value is read from the ro.boot.slot_suffix build property.
That being said, you might be able to just repartition your device to only have 1 slot, flash your ROM, and use
Code:
fastboot --set-active=_a
. If your ROM has disabled OTA updates from the OEM, you should be fine.
I'm going to get an X4 in the coming weeks. I'd like to help with this soon. I'm a seasoned developer by trade and can collab on GitHub. Hope to be able to start working with you soon. :good:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Hariiiii said:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Click to expand...
Click to collapse
@vache at the Moto G5 Plus forums has already managed it using the /oem partition which is otherwise unused for custom ROMs
Hariiiii said:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Click to expand...
Click to collapse
Cool... seems it may be possible. Will follow the progress on the Redmi and G5 devices
navenedrob said:
I'm going to get an X4 in the coming weeks. I'd like to help with this soon. I'm a seasoned developer by trade and can collab on GitHub. Hope to be able to start working with you soon. :good:
Click to expand...
Click to collapse
The more I am reading about enabling Treble, the more I think it is entirely possible.... and probably the best direction to focus our efforts.
Seems like we have partitions that could be used as /vendor. I am reading up on exactly how the Treble vendor partition is set up. Tricky, but not implausible.
EDIT: Actually, none of the partitions we could potentially re-purpose for /vendor are big enough. So, it may be harder on this device than on others. It may require repartitioning.