Eric Park (ideaman924)
Communities and Collections
Posts
I make stuff. I break stuff. I do stuff. I think stuff. I am stuff. Lead Maintainer, Core Developer for #TeamBliss
Post has attachment
Teasers!
* Note that this is a compilation from our super secret rooms. I did not make all of it.
Introducing your future device maintainers (subject to change)
Aren Clegg - Nexus 5 (hammerhead), 7 (deb)
Eric Park (me) - Nexus 5X (bullhead)
PLEASE DON’T BOTHER BUGGING ANY OF OUR TEAM MEMBERS FOR BUILDS OR ETAS. DOING SO WILL GET YOU BANNED AND IN THE FUTURE I’LL STOP POSTING TEASERS.
More devices to come. Stay tuned and stay Bliss!
* Note that this is a compilation from our super secret rooms. I did not make all of it.
Introducing your future device maintainers (subject to change)
Aren Clegg - Nexus 5 (hammerhead), 7 (deb)
Eric Park (me) - Nexus 5X (bullhead)
PLEASE DON’T BOTHER BUGGING ANY OF OUR TEAM MEMBERS FOR BUILDS OR ETAS. DOING SO WILL GET YOU BANNED AND IN THE FUTURE I’LL STOP POSTING TEASERS.
More devices to come. Stay tuned and stay Bliss!
‹
›
17. 10. 9.
3 Photos - View album
Update! August 24th, 2017
1. Social Media
I've disabled pre-approval content moderation for our G+ page. It had been enabled for the last month as a test case, but the idea was eventually scrapped because we, I mean specifically I, had trouble keeping up with the stream of posts. Therefore, your posts will probably show up faster.
I've also gone around the page, removing offensive material and certain pages pointing to fake religion. Anybody that posts these kinds of content will be permanently banned, no exceptions or excuses.
2. Website
Moving on to fun stuff!
The website has been largely revamped by +Jon West, +Henri Koivuneva and +Călin Neamţu. Thanks to all the developers and designers that put the time and effort into making something wonderful!
As you can probably see, we've moved away from dynamic web content to static web content for faster viewing times while still keeping the elegancy and beauty of modern web designs. We hope you enjoy the experience!
Moreover, +Călin Neamţu has been hard at work setting up a database for all the developers and maintainers and getting the database to work alongside the website. Thank him for the awesome work!
As always, the website is always a constant Work In Progress because we strive for perfection down to that last pixel count. So stay tuned for more improvements!
3. Android Oatmeal Cookie
Yes, I'm trolling you guys. We all know it's Oreos
+Jack has already started work on the o8.0 branch, pushing out a stream of commits to Gerrit before we even noticed! +Vaughn Newman is also getting the branch up to tack, so you will have to wait until we come out with a testing version!
That's all I can say for now. Stay #Bliss!
1. Social Media
I've disabled pre-approval content moderation for our G+ page. It had been enabled for the last month as a test case, but the idea was eventually scrapped because we, I mean specifically I, had trouble keeping up with the stream of posts. Therefore, your posts will probably show up faster.
I've also gone around the page, removing offensive material and certain pages pointing to fake religion. Anybody that posts these kinds of content will be permanently banned, no exceptions or excuses.
2. Website
Moving on to fun stuff!
The website has been largely revamped by +Jon West, +Henri Koivuneva and +Călin Neamţu. Thanks to all the developers and designers that put the time and effort into making something wonderful!
As you can probably see, we've moved away from dynamic web content to static web content for faster viewing times while still keeping the elegancy and beauty of modern web designs. We hope you enjoy the experience!
Moreover, +Călin Neamţu has been hard at work setting up a database for all the developers and maintainers and getting the database to work alongside the website. Thank him for the awesome work!
As always, the website is always a constant Work In Progress because we strive for perfection down to that last pixel count. So stay tuned for more improvements!
3. Android Oatmeal Cookie
Yes, I'm trolling you guys. We all know it's Oreos
+Jack has already started work on the o8.0 branch, pushing out a stream of commits to Gerrit before we even noticed! +Vaughn Newman is also getting the branch up to tack, so you will have to wait until we come out with a testing version!
That's all I can say for now. Stay #Bliss!
Post has attachment
Read before posting!
1. SEARCH FIRST. There will certainly almost always be other people who have encountered the problem first. If so, they would've asked too and might have even gotten an answer. Do not make duplicates, please!
2. Include the device name, build version, and whether you're clean flashing or dirty flashing. Please list all steps you took prior to the incident, bug, or force crash.
3. Please refer to this handy guide to take proper bug reports. https://raw.githubusercontent.com/nathanchance/Android-Tools/master/Guides/Proper_Bug_Reporting.txt
4. Typically you can upload the logs to Pastebin or Hastebin but a better solution might be to include the log as a text file. Browsers lag with huge output, remember.
Happy bug hunting!
Eric
Edit: the comments section is not where you post questions. Locking the thread. Please make questions on the discussion board.
1. SEARCH FIRST. There will certainly almost always be other people who have encountered the problem first. If so, they would've asked too and might have even gotten an answer. Do not make duplicates, please!
2. Include the device name, build version, and whether you're clean flashing or dirty flashing. Please list all steps you took prior to the incident, bug, or force crash.
3. Please refer to this handy guide to take proper bug reports. https://raw.githubusercontent.com/nathanchance/Android-Tools/master/Guides/Proper_Bug_Reporting.txt
4. Typically you can upload the logs to Pastebin or Hastebin but a better solution might be to include the log as a text file. Browsers lag with huge output, remember.
Happy bug hunting!
Eric
Edit: the comments section is not where you post questions. Locking the thread. Please make questions on the discussion board.
Commenting is disabled for this post.
Well, I've been distro-hopping for the past few weeks. I think I've tried all the distros out there, including beginner oriented distros like Linux Mint.
One thing I noticed was that none of the distros support my RX 480. I use Blender frequently, but I cannot get the GPU to show up under the Cycles settings. All the other distros do not detect my card properly, either.
Is this a problem with the amdgpu open source drivers? If so, AMD is really shitty with their updates. I heard from some forums that the graphics card was properly detected with the proprietary ones. Shortly thereafter AMD abandoned development on the proprietary one to work on the open sourced one. Problem is, AMD isn't working fast enough to get the open source driver up to snuff.
This is a big problem since I want everything to just work when I set up my distro. I mean, I could search through Google for solutions and alternative drivers, but when there isn't any, then it disturbs my work flow. Right now, I'm back on Windows, but if you guys have any solutions to get the card working, then I'll gladly switch.
One more thing. My laptop has a QCA6174 wifi card from Qualcomm Atheros. It is properly detected, but unfortunately I get a 1Mbps down up link speed. Compare that to 400Mbps on Windows and I'm starting to suspect something is wrong here. Any ideas?
One thing I noticed was that none of the distros support my RX 480. I use Blender frequently, but I cannot get the GPU to show up under the Cycles settings. All the other distros do not detect my card properly, either.
Is this a problem with the amdgpu open source drivers? If so, AMD is really shitty with their updates. I heard from some forums that the graphics card was properly detected with the proprietary ones. Shortly thereafter AMD abandoned development on the proprietary one to work on the open sourced one. Problem is, AMD isn't working fast enough to get the open source driver up to snuff.
This is a big problem since I want everything to just work when I set up my distro. I mean, I could search through Google for solutions and alternative drivers, but when there isn't any, then it disturbs my work flow. Right now, I'm back on Windows, but if you guys have any solutions to get the card working, then I'll gladly switch.
One more thing. My laptop has a QCA6174 wifi card from Qualcomm Atheros. It is properly detected, but unfortunately I get a 1Mbps down up link speed. Compare that to 400Mbps on Windows and I'm starting to suspect something is wrong here. Any ideas?
Updates! October 13th, 2017
Halloween draws nearer, and so do candies and sweet things. Bliss 8.0 (aka Oreo) is coming closer and closer for a public beta candidate.. so what has been going on behind the scenes?
First off, we’re making headway progress! We’ve managed to get a lot of devices up and running. The full list (for now) includes (All usernames are Telegram handles):
Nexus Devices
Nexus 4 (mako, @Nitin1438)
Nexus 5 (hammerhead, @aclegg2011)
Nexus 5X (bullhead, @ideaman924)
Nexus 6 (shamu, @rwaterspf1)
Other
ZTE Warp Sync (warp4, @bcrichster) *Running Nougat for now
And more devices will be on the way in the future!
Secondly, we’re making some good time in development. We’ve been short of staff lately, but that doesn’t stop us from working hard! Unfortunately, I cannot disclose anything related to development, because for one, I don’t know enough to even make heads or tails out of anything. And for another, it’s a surprise. If you really want to follow along as we develop, you can visit us on our GitHub page where we disclose full open-sourced code and also on Gerrit where you can see the tick-tock between the developers minds!
I know you guys were all excited to see Bliss come out soon. We’re making some great headway, and I can promise it will come out soon. But no requests for ETAs, remember!
As for other areas of development, on Bliss-x86 project, we have been making quite a few updates to our Nougat branch in preparation for one final release. New features include updated mesa, added Swiftshader for unsupported GPU hardware (and headless operation) and we are busy, busy, busy on updating the bootable/new-installer to improve on quite a few things. Shoutout to @Vioner for offering to help out there. Bliss-x86 Oreo development is going slow not just for Bliss, but our partners at Android-x86 project as well, and only VM images have been bootable so far. So we are taking some time to explore other options for the issues we are having with Oreo on PC’s. We will update more on this bit at a later date.
Bliss Nougat for Pinebook and Pine64 was updated to support Widevine DRM (for Netflix and other video services) as well as a few minor updates, added features and improvements to Freeform window behaviour. So far no negative feedback from this release, so we are counting that as a WIN!
So that's it for this week guys! It's a Friday, so why not go and party?
Halloween draws nearer, and so do candies and sweet things. Bliss 8.0 (aka Oreo) is coming closer and closer for a public beta candidate.. so what has been going on behind the scenes?
First off, we’re making headway progress! We’ve managed to get a lot of devices up and running. The full list (for now) includes (All usernames are Telegram handles):
Nexus Devices
Nexus 4 (mako, @Nitin1438)
Nexus 5 (hammerhead, @aclegg2011)
Nexus 5X (bullhead, @ideaman924)
Nexus 6 (shamu, @rwaterspf1)
Other
ZTE Warp Sync (warp4, @bcrichster) *Running Nougat for now
And more devices will be on the way in the future!
Secondly, we’re making some good time in development. We’ve been short of staff lately, but that doesn’t stop us from working hard! Unfortunately, I cannot disclose anything related to development, because for one, I don’t know enough to even make heads or tails out of anything. And for another, it’s a surprise. If you really want to follow along as we develop, you can visit us on our GitHub page where we disclose full open-sourced code and also on Gerrit where you can see the tick-tock between the developers minds!
I know you guys were all excited to see Bliss come out soon. We’re making some great headway, and I can promise it will come out soon. But no requests for ETAs, remember!
As for other areas of development, on Bliss-x86 project, we have been making quite a few updates to our Nougat branch in preparation for one final release. New features include updated mesa, added Swiftshader for unsupported GPU hardware (and headless operation) and we are busy, busy, busy on updating the bootable/new-installer to improve on quite a few things. Shoutout to @Vioner for offering to help out there. Bliss-x86 Oreo development is going slow not just for Bliss, but our partners at Android-x86 project as well, and only VM images have been bootable so far. So we are taking some time to explore other options for the issues we are having with Oreo on PC’s. We will update more on this bit at a later date.
Bliss Nougat for Pinebook and Pine64 was updated to support Widevine DRM (for Netflix and other video services) as well as a few minor updates, added features and improvements to Freeform window behaviour. So far no negative feedback from this release, so we are counting that as a WIN!
So that's it for this week guys! It's a Friday, so why not go and party?
Post has shared content
This is my thoughts on what Jon posted a few days ago. In his post, he talks about the idea of standardizing the base ROM of all Android ROMs so that we could work more efficiently. Features and devices would be more easier to implement and port over, and ultimately make developing a little easier for devs.
But I’m not sure I agree with this idea. Basically, standards are OK, until it gets too big. Then it becomes one hell of a mess to deal with and patch over.
The W3C debate over DRM recently is one of the flaws of standardizations. Sure, you could argue the major media corporations have been lobbying for this change a lot, but because of the players and voters in the committee, the change was accepted into the standardization and now we have no choice but to embrace this standard. Remember cookies in browsers? Yes, it’s that all over again.
Basically, it’d be the same in this idea. We’d make a pretty good standard, and lots of ROMs would decide to use it. Until, some big change that warrants everyone’s attention comes out, such as a change that asks for balance between features and appearances. Not everyone would agree on this, and ROMs would start to take on variations to address the users. And then a vote would take place on the base ROM, and eventually one side will win and be included into the standard, ostracizing the other ROMs that have chosen to go with the other side.
Or, it could be even more troublesome. Maybe there’s a commit that allows infinite customizations to device trees, HALs, vendor trees and kernel sources, as long as devs take the time to write them properly, or there might be a dog-simple commit where the base ROM does the grunt work of initializing the trees while not allowing any form of custom stuff in the trees. Again, these kinds of things would spark another argument and heated discussion in the ROM space until the change gets accepted into the base ROM that leaves out the other commit.
I’m certainly putting on my tinfoil hat here, and not everything will be like this, for sure. But it certainly gives one to think about whether standardizing everything is a correct move. Your thoughts and opinions are welcome in the comments section.
But I’m not sure I agree with this idea. Basically, standards are OK, until it gets too big. Then it becomes one hell of a mess to deal with and patch over.
The W3C debate over DRM recently is one of the flaws of standardizations. Sure, you could argue the major media corporations have been lobbying for this change a lot, but because of the players and voters in the committee, the change was accepted into the standardization and now we have no choice but to embrace this standard. Remember cookies in browsers? Yes, it’s that all over again.
Basically, it’d be the same in this idea. We’d make a pretty good standard, and lots of ROMs would decide to use it. Until, some big change that warrants everyone’s attention comes out, such as a change that asks for balance between features and appearances. Not everyone would agree on this, and ROMs would start to take on variations to address the users. And then a vote would take place on the base ROM, and eventually one side will win and be included into the standard, ostracizing the other ROMs that have chosen to go with the other side.
Or, it could be even more troublesome. Maybe there’s a commit that allows infinite customizations to device trees, HALs, vendor trees and kernel sources, as long as devs take the time to write them properly, or there might be a dog-simple commit where the base ROM does the grunt work of initializing the trees while not allowing any form of custom stuff in the trees. Again, these kinds of things would spark another argument and heated discussion in the ROM space until the change gets accepted into the base ROM that leaves out the other commit.
I’m certainly putting on my tinfoil hat here, and not everything will be like this, for sure. But it certainly gives one to think about whether standardizing everything is a correct move. Your thoughts and opinions are welcome in the comments section.
I’d like to take a moment from our normal routine to address a couple issues I’ve observed within the Android development community. Now I’m gonna leave you hanging there for a minute while I tell you a story.
Once upon a time in our little corner of the universe, there were a few people that saw the changes happening with Android development, and saw the need to unite as a team, and create a good solid Open Source ROM for others to use, adapt and add to. This is the team that pretty much started something really good for the community, but it grew too big and went in too many directions for it to effectively fulfil the need to the community it once did.
Fast forward about 7 years, and the growth of that team led to it falling apart. Yes, the ROM lives on under a different name, but the gap in the needs of the community carried on.
There were many that tried to fill that gap, but as time went on, the work needed was too large for just a few to work on and keep up with outside their daily lives. While the rest of the community did nothing to contribute towards the future of the base projects, they only forked it in order to make their own. And this is where the story takes a turn.
There was a need for a new base ROM, because most teams and ROM developers have been spending their time working on bringing up device trees, or taking a fork of someone else’s ROM, and stripping away the branding, added SDK’s, etc. just to get things to a point where forward movement could commence. This is where one of our issues lies too. There is a need for a new kind of base ROM that everyone can use, and while we’re at it, I’d like to suggest we make it easy for people to learn from as well. I’ll be honest and admit that the majority of us really need to work at better documenting our commits and changes, and I’ll leave that at that for now.
The new base should work with ANY device config; los, aosp, du, omni, bliss, etc. We should be keeping the variants list in our Vendor too, and allow other teams to add their device prefixes to it. It should also move away from making changes directly to AOSP I feel. We can use /build/… in our vendor and device configs for any changes needed to be made on top of AOSP for added functions. For this project, we should also consider making the move away from adding directly to frameworks as well, but that is a task easier said than done. And the need for common SDK’s might also not be there any longer, but that is a story for a different post.
Why are we all spending so much of our time working towards what we picture as end goal for our own perspective view, when we could be working together towards a much grander view, allowing all the effort and time being put into getting things up to a point where forward movement can take place to be put into future innovation instead. Doing this will widen the compatibility across the board and speed production, allowing us to only have to keep a few things added to the actual AOSP code in order to truly expand on things.
Now, I do have to hand out a few props to the community for starting on this idea or something similar, but I would also like to say that I feel we might be doing it all wrong. We need to be doing it unbranded and there’s only one small team that has tried that. I know a few on Bliss Family have toyed with this idea as well as AOSP-CAF & GZR, and I give you all mad props, but I feel our biggest hold up on the idea is that we brand it as our own. THIS is where I feel we have built walls as ROM teams. Our branding might identify us and help to add to a prestige or lineage, but I feel it is that ego that has slowly been destroying our community of developers from day one. So this new base must also try and remove the EGO as well. We now have a need to form a team once again that has no wall, no brand, no ego and no boundaries, but has a sole purpose towards setting a new stage for development and allowing forward innovation to move as fast as possible within the community.
And to those wondering why I’m putting this out there? There are some things you might see that need to be changed about the environment around you, but you feel are too big to change by yourself. Don’t hold onto your observations, because they will grow stale and lose their spark. Share the ones you can’t do alone. Because the community is always listening and change will happen, even if you can’t facilitate that change yourself.
I’m open to having a serious conversation about this with any other teams or developers. Our schedule is an open book, so don’t be afraid to reach out to either me.
Once upon a time in our little corner of the universe, there were a few people that saw the changes happening with Android development, and saw the need to unite as a team, and create a good solid Open Source ROM for others to use, adapt and add to. This is the team that pretty much started something really good for the community, but it grew too big and went in too many directions for it to effectively fulfil the need to the community it once did.
Fast forward about 7 years, and the growth of that team led to it falling apart. Yes, the ROM lives on under a different name, but the gap in the needs of the community carried on.
There were many that tried to fill that gap, but as time went on, the work needed was too large for just a few to work on and keep up with outside their daily lives. While the rest of the community did nothing to contribute towards the future of the base projects, they only forked it in order to make their own. And this is where the story takes a turn.
There was a need for a new base ROM, because most teams and ROM developers have been spending their time working on bringing up device trees, or taking a fork of someone else’s ROM, and stripping away the branding, added SDK’s, etc. just to get things to a point where forward movement could commence. This is where one of our issues lies too. There is a need for a new kind of base ROM that everyone can use, and while we’re at it, I’d like to suggest we make it easy for people to learn from as well. I’ll be honest and admit that the majority of us really need to work at better documenting our commits and changes, and I’ll leave that at that for now.
The new base should work with ANY device config; los, aosp, du, omni, bliss, etc. We should be keeping the variants list in our Vendor too, and allow other teams to add their device prefixes to it. It should also move away from making changes directly to AOSP I feel. We can use /build/… in our vendor and device configs for any changes needed to be made on top of AOSP for added functions. For this project, we should also consider making the move away from adding directly to frameworks as well, but that is a task easier said than done. And the need for common SDK’s might also not be there any longer, but that is a story for a different post.
Why are we all spending so much of our time working towards what we picture as end goal for our own perspective view, when we could be working together towards a much grander view, allowing all the effort and time being put into getting things up to a point where forward movement can take place to be put into future innovation instead. Doing this will widen the compatibility across the board and speed production, allowing us to only have to keep a few things added to the actual AOSP code in order to truly expand on things.
Now, I do have to hand out a few props to the community for starting on this idea or something similar, but I would also like to say that I feel we might be doing it all wrong. We need to be doing it unbranded and there’s only one small team that has tried that. I know a few on Bliss Family have toyed with this idea as well as AOSP-CAF & GZR, and I give you all mad props, but I feel our biggest hold up on the idea is that we brand it as our own. THIS is where I feel we have built walls as ROM teams. Our branding might identify us and help to add to a prestige or lineage, but I feel it is that ego that has slowly been destroying our community of developers from day one. So this new base must also try and remove the EGO as well. We now have a need to form a team once again that has no wall, no brand, no ego and no boundaries, but has a sole purpose towards setting a new stage for development and allowing forward innovation to move as fast as possible within the community.
And to those wondering why I’m putting this out there? There are some things you might see that need to be changed about the environment around you, but you feel are too big to change by yourself. Don’t hold onto your observations, because they will grow stale and lose their spark. Share the ones you can’t do alone. Because the community is always listening and change will happen, even if you can’t facilitate that change yourself.
I’m open to having a serious conversation about this with any other teams or developers. Our schedule is an open book, so don’t be afraid to reach out to either me.
Post has shared content
Grab your t shirts!
Bliss is holding a T-Shirt fundraiser to help us reach our business goals and file for nonprofit status. Grab one and help support a great cause in style!!
https://www.customink.com/fundraising/bliss-t-shirt-fundraiser
https://www.customink.com/fundraising/bliss-t-shirt-fundraiser
Post has attachment
Read before posting!
1. "Is device X supported...?"
You can check http://blissroms.com, which lists all the devices that are currently supported. Alternatively you can check http://downloads.blissroms.com to see current and past releases for all devices.
Please remember that posts with this topic may be removed without any notice. If you slip through the spam filter you may also find yourself in a puddle of ridicule. Please don't ask, first search, and when you can't find it then ask!
Edit: I'm not joking. I had to disable the comments because people are asking if their devices are compatible. If you make these kinds of posts to annoy us then assume before posting that you might be banned without given notice.
2. "Is device Y scheduled to be supported..?"
You can check the Alpha or Maintenance folders in the downloads website. Typically these will have unstable builds from new maintainers. If you don't see a build there, please don't ask.
If you ask, we need to ask around the team chat, questioning who is currently developing for a device. Not only does this take a long time, this also adds a lot of unnecessary overhead to development. So please don't ask these kinds of questions.
WARNING! Alpha or Maintenance builds are unstable! They can make your device unstable or worst case scenario, potentially brick your device. We do try and test all releases but we do not take any responsibility for your actions. Please be careful.
3. Ads and other harmful content
If you see any ads on the page, please flag them ASAP for us to review! Typically they will be the ones to skip through our spam filter, and we'll make sure to remove them.
If you see any harmful or inappropriate content, flag them as well. We also have the ability to ban certain users from posting more harmful content, so don't hesitate to report inappropriate material!
Happy flashing!
Eric
1. "Is device X supported...?"
You can check http://blissroms.com, which lists all the devices that are currently supported. Alternatively you can check http://downloads.blissroms.com to see current and past releases for all devices.
Please remember that posts with this topic may be removed without any notice. If you slip through the spam filter you may also find yourself in a puddle of ridicule. Please don't ask, first search, and when you can't find it then ask!
Edit: I'm not joking. I had to disable the comments because people are asking if their devices are compatible. If you make these kinds of posts to annoy us then assume before posting that you might be banned without given notice.
2. "Is device Y scheduled to be supported..?"
You can check the Alpha or Maintenance folders in the downloads website. Typically these will have unstable builds from new maintainers. If you don't see a build there, please don't ask.
If you ask, we need to ask around the team chat, questioning who is currently developing for a device. Not only does this take a long time, this also adds a lot of unnecessary overhead to development. So please don't ask these kinds of questions.
WARNING! Alpha or Maintenance builds are unstable! They can make your device unstable or worst case scenario, potentially brick your device. We do try and test all releases but we do not take any responsibility for your actions. Please be careful.
3. Ads and other harmful content
If you see any ads on the page, please flag them ASAP for us to review! Typically they will be the ones to skip through our spam filter, and we'll make sure to remove them.
If you see any harmful or inappropriate content, flag them as well. We also have the ability to ban certain users from posting more harmful content, so don't hesitate to report inappropriate material!
Happy flashing!
Eric
Commenting is disabled for this post.
Uuuppddaattess July 11th, 2017
Dammit Eric, where's my bullhead build??!?
Fear not, for today is the day I get to actually build successfully. I've gotten in touch with franciscofranco, and suffice to say he has gotten my build system to function correctly once again.
! For those of you folks who can't build Franco's kernel, try using the defconfig in /proc/config.gz. All you have to do is copy the file within the archive into the kernel's arch/[arm/arm64]/configs folder, then change the appropriate defconfig line in the BoardConfig.mk, which is in device/[lge]/[bullhead]
And there's more. Unfortunately, the guy at the LG service center forgot to check if the proximity sensor was working. I asked him for hours on end when I submitted the device for repair, to please, please please make sure the sensor is working because there's been numerous reports that after the repair it doesn't work. Apparently he has a hearing problem, he was just plain lazy, or he forgot. Or all three.How can you forget if you never hear it, genius?
So the 5X is going in for repair once again. I'm betting this device won't last this year. Who wants to bet me a new phone thats NOT the 5X so I can continue development?
Finally, one last bit before I go. Magisk may not work correctly. If you're experiencing problems with Magisk causing the WebView or the provider to disappear, if your Developer Options menu is gone after the flash, please uninstall Magisk! I'm still tracking down what's the problem but it may also have something to do with my constant dirty flashes. :(
Edit: Just been to the service center. Apparently there was a problem when the device was reassembled. Stupid me for not trying it myself at home. An another engineer profusely apologized, so at least the experience was OK.
Dammit Eric, where's my bullhead build??!?
Fear not, for today is the day I get to actually build successfully. I've gotten in touch with franciscofranco, and suffice to say he has gotten my build system to function correctly once again.
! For those of you folks who can't build Franco's kernel, try using the defconfig in /proc/config.gz. All you have to do is copy the file within the archive into the kernel's arch/[arm/arm64]/configs folder, then change the appropriate defconfig line in the BoardConfig.mk, which is in device/[lge]/[bullhead]
And there's more. Unfortunately, the guy at the LG service center forgot to check if the proximity sensor was working. I asked him for hours on end when I submitted the device for repair, to please, please please make sure the sensor is working because there's been numerous reports that after the repair it doesn't work. Apparently he has a hearing problem, he was just plain lazy, or he forgot. Or all three.
So the 5X is going in for repair once again. I'm betting this device won't last this year. Who wants to bet me a new phone thats NOT the 5X so I can continue development?
Finally, one last bit before I go. Magisk may not work correctly. If you're experiencing problems with Magisk causing the WebView or the provider to disappear, if your Developer Options menu is gone after the flash, please uninstall Magisk! I'm still tracking down what's the problem but it may also have something to do with my constant dirty flashes. :(
Edit: Just been to the service center. Apparently there was a problem when the device was reassembled. Stupid me for not trying it myself at home. An another engineer profusely apologized, so at least the experience was OK.
Wait while more posts are being loaded