yashsingh1/xdaforums huggingface dataset:
[JAM, MDA Compact, S100 Software Upgrading] 2234jones:
http://www.airfagev.com/forum_view.asp?msg_id=169074

try this
[JAM, MDA Compact, S100 Software Upgrading] Eikichi:
First, GStart which is created by the great greatbal is for smartphones not PPCs. Second, it only enables Grid type icons instead of the usual list type ones found on older 2003 and below smartphones. Third, it does not emulate anything, its a standalone program and will not make your Jams or minis boot WM5. Although thats a nice idea though, if one could emulate WM5 on the magician (2003SE) just like devhook does for the PSP you can have the best of both worlds at your beck and call.
[Device Repair] XDARoni:
Best Websites For Android Parts

Before you go searching all over the internet to try and find a trusted website that sells the Android part you're looking for, you might want to take a quick look at this list of websites. We've all had those experiences where our parts show up mangled in poor packaging and broken. To avoid this problem let's use the websites that are used by professionals throughout the industry of smartphone repair.

Swappa Boneyard

View attachment 3607370

Swappa is a favorite among XDA users and is an awesome website for used phones and spare parts. You'll find a section called the junkyard where users can sell broken phones. Give it a glance and see if anyone is selling the phone that you need a part for. Even if you just need a charge port or something, having those extra parts might come in useful later on.

iFixit

View attachment 3607372

Definitely the most popular in the list, these guys take their business seriously. They have a wide variety of parts, tools and even teardown instructions. For almost every new product that comes out, they'll have a teardown video that shows you exactly what tools to use and how to take the phone apart. They also use high quality parts which are sometimes worth paying a little extra.

Directfix

View attachment 3607373

Directfix is where you go to get the absolute cheapest price. Very rarely do I find a website that is offering lower prices than they are. They also have repair directions and videos to check out if you need a little help with your repair project.

Repair Universe

View attachment 3607371

Repair Universe is great because of their huge selection of parts that they have available. Usually this is the place you'll end up if you're looking for that really obscure part that nobody else seems to have. Their shipping is fast as well so if you're in a pinch they might be the best option.

ebay

View attachment 3607369

The situations where I would recommend using ebay is when it's a specific part that you can't find on other websites, or if you're looking to get a broken phone to be used for parts. You have to be careful on ebay because you're usually buying from people who do not make their living off of smartphone parts alone. Because of this you will sometimes get low quality parts and they often break in the mail. Be sure to check your seller to make sure everything looks good before you buying from anyone.

Stick to these websites and you can rest assured that you're in good hands.
[Device Repair] aarowm:
I've ordered several parts for multiple devices from Amazon.com on different occasions. So far I've had no problems. It's mostly been screen glass and LCD's. However, I recently bent my note 4. The glass didn't break but the frame is bent considerably. I ordered a new frame from Amazon.com for 30 and free shipping. When it gets here I'll be swapping frames. Now to keep the glass from breaking dieting dissasembly.

I had a friend order a LCD and glass for her Note 10.1 2014 edition from eBay recently. It looked fine and in a pre install test it seamed to work ok. After it was installed the randomly quits responding to touch and it does not recognize the s-pen at all. It was advertised as being for a note but I think it was for the tab version. My friend is now trying to get a replacement but they don't want to exchange it because it was installed.

I guess the lesson here is to be careful no matter where you get your parts.

And thanks DrGreenway for the above list. :good:
[Device Repair] ajaytrigune:
Thank You Sir.:good:
[Device Repair] milewap:
God news for my,old ZTE :)
[Device Repair] GuestK0087:
One of my most trusted sources for parts:

http://gadgetfix.com

They also have an eBay store.

No hassle returns and many shipping options available. :good:
[Device Repair] webbygiants:
I would like to recommend iFixit from the list. This is a best place where you get all the tools and parts for your Android device.
[Device Repair] RonChinoy:
I dont see aliexpress on this list. Amazing selection of spares and chips.
[Xperia Z3 Compact Q&A, Help & Troubleshooting] dmillburn:
Something slightly odd happened just now - my Z3C popped up with a Xperia System Update telling me it was ready to install to 23.4.A.1.264 just now. This is slightly confusing as I'm already on that version and have been for some time (I flashed a pre-rooted rom via recovery weeks ago). I doubled checked to make sure my mind wasn't playing tricks on me and the phone reports it is definitely on 23.4.A.1264. The message came back after a reboot so I've just selected to postpone the update and set reminders to "never" but why is this happening?

Edit- meant to post this in Q&A - sorry, can a mod move it for me?
[Xperia Z3 Compact Q&A, Help & Troubleshooting] endlesstrail:
No idea. I've received the same update as well.
[Xperia Z3 Compact Q&A, Help & Troubleshooting] Watevah:
Same for me. Just got one a few hours ago.
[Xperia Z3 Compact Q&A, Help & Troubleshooting] andrewia:
I also got the notice. I have Xposed installed and have modified the kernel with dual recovery. Does everyone else have a similar setup? Maybe the OTA service has issues detecting the system version after some partitions have been modified.
[Xperia Z3 Compact Q&A, Help & Troubleshooting] shuiheart:
I am fully stock and I got the same update. It did nothing but restart my phone.
[Xperia Z3 Compact Q&A, Help & Troubleshooting] dmillburn:
At least it's not just me then. It's very persistent though, despite setting it to postpone forever it still keeps giving the message each day.
[Xperia Z3 Compact Q&A, Help & Troubleshooting] madd0g:
January Android bugfix, supposed to fully fix stagefright.
[Xperia Z3 Compact Q&A, Help & Troubleshooting] andrewia:
I haven't updated and I haven't seen the update recently. I guess Sony fixed it on their end.
[Android Q&A, Help & Troubleshooting] ravi124:
Can anyone help me out to root my device intex cloud flash 4g plzzzzz
[SuperSU] Chainfire:
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.

By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.

This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.

Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
[SuperSU] NZgeek:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.

I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
[SuperSU] garyd9:
The problems with the existing solution are:

1. It blindly alters the system kernel behavior for every single device samsung manufactures.

2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.

3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)

4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)

Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.

Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?

My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.

Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)

Take care

Gary
[SuperSU] Chainfire:
[MENTION=336863]garyd9[/MENTION] [MENTION=4163343]NZgeek[/MENTION]

Some good points are raised. I am not going to go into them all individually.

There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).

While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.

Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.

Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?

It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.

Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.

I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.

for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
[SuperSU] garyd9:
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:

https://goo.gl/photos/61JWzoA5ir3PcDNr9

(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://xdaforums.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)

Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. ;) (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)
[SuperSU] Chainfire:
Please do let me know if I can be of further assistance to fix compatibility.

I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...

Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?

Complete guesswork, but the backing file may need to be released for the loop device.

Any idea why?

I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.

Where is this?
[SuperSU] nkk71:
Thank you, I will let you know once I've had a chance to properly debug further :o

I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done :D

(at the time it was SuperSU v2.65)

No need to take double symlinks into account, only the real one is changed as follows:

the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:

cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...

all other symlinks to the block device remain as is:

cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...

Will check, thanks.

Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)

at the beginning of launch_daemonsu.sh:

if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem

^^ I commented all three of them out, which worked out fine.

MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot

I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.

EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9
[SuperSU] garyd9:
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):

scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1

The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):

scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0

So far, all indications are that the change suggested would work.

Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
[SuperSU] Chainfire:
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
[SuperSU] dr.ketan:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.

echo 'write back' > /sys/class/scsi_disk/$i/cache_type

and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)

So if i had test with

echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type

then 0000 also get cached right?

It shouldn't be problem right? Just references to this post last line.

Regards
[SuperSU] Chainfire:
I don't know, since you changed it up, and your statement is a bit confusing.

Try this:

for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done

Copy/paste the output.
[SuperSU] dr.ketan:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
[SuperSU] Chainfire:
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
[SuperSU] dr.ketan:
u0_a259@noblelte:/ $ su

root@noblelte:/ # ls -l /sys/class/scsi_disk/

lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:3root@noblelte:/ # cat /sys/class/scsi_disk/*/write_protect

0

1

1

1

root@noblelte:/ #
[SuperSU] Chainfire:
Seems fine!
[SuperSU] nkk71:
I had some time to check a few things, so please find below my findings / possibly solutions

Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)

(at line 1199 of SuperSU 2.66 updater-binary):

if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi

Turns out the loop device was in fact the problem; after umount /su, it still showed:

~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img

so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)

umount /su
[B]losetup -d /dev/block/loop0[/B]

I know it was on loop0 so I didnt need to account for anything else, but maybe using

LOOPDEVICE=`losetup -f`

or something similar, and continuing from there could be an option

Haven't tried checking on the other issues, but will report back when I have something on those
[SuperSU] garyd9:
[MENTION=631273]Chainfire[/MENTION], early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
[SuperSU] Chainfire:
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.

This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...

Good news, as expected.
[SuperSU] nkk71:
If it's just regarding MultiROM Recovery versions, then I believe I can fix the loop device release, even without touching your script; MultiROM Recovery does indeed release loop devices, but after it tries to unmount the partitions first; I could rewrite that, to release /data/su.img before starting the other unmounts.

But regarding the dd command, that's going to be an issue... we could work around it with some kind of specific check just for this, but that is not ideal; I'm sure you have your reasons why to first null out the partition (not needed on my devices), before flashing the real kernel, but if the readlink & block device checks are unreliable, perhaps just limit the amount of data dd nulls out

giving dd "free reign" to null out as much as it possible can, could also be potentially unwanted for other recoveries/devices
[SuperSU] Chainfire:
Oh, I wasn't saying the changes won't happen, just that it may not be a copy/paste of what you stated.

For example, the way it will be used in the script with the expected input and output, "readlink -f FILE" can be replaced with "readlink FILE || echo FILE" twice.

Similarly, instead if "if -b" a "grep /dev/block" after using readlink should work.

Is it 100% foolproof? No. But I'll bet it'll work on every recovery/device currently out there.

As for releasing /data/su.img, I will definitely put this into the script as well. No need to patch MultiROM.
[SuperSU] Chainfire:
Please see the attached version.

Reading again through this thread, I believe the following issues have been fixed:

- The symlink of the boot image partition to somewhere outside /dev/block is now detected, and the wipe skipped

- The loop device link to the /data/su.img or /cache/su.img file is now released after unmount

- The remount_ro section in launch_daemonsu.sh has been removed, as I now have a different workaround for the remount r/w issue

- If 'setprop sukernel.mount 1' fails to mount, a fallback attempt is made with losetup

That should cover all the issues you raised (correct me if I'm wrong), and hopefully this makes the entire thing work with MultiROM. Please do let me know :)
[SuperSU] nkk71:
A late reply (I see 2.67 is already out), but ran into a little hiccup :eek:

But can confirm all issues are fixed with your attached zip for MultiROM :good::good:

Installer

no longer causes unneccessary wiping

releases loop device fine

.

Bootup behaves as expected

first boot will reboot after installing the apk

second boot works fine, SuperSU fully functional

Many thanks [MENTION=631273]Chainfire[/MENTION] :highfive:

If I figure out why the setprop didnt work, I'll post back

Also, just an fyi, not sure how important / relevant / intended they are, since SuperSU flashes and works just fine:

1- extract of recovery.log:

- System-less mode, boot image support required
- Creating image
Creating filesystem with parameters:
Size: 33554432
Block size: 4096
Blocks per group: 32768
Inodes per group: 2048
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 8192
Block groups: 1
Reserved block group size: 7
Created filesystem with 11/2048 inodes and 1166/8192 blocks
/data/su.img: clean, 11/2048 files, 1166/8192 blocks
- Mounting image
mknod: /dev/block/loop0: File exists
[B][COLOR="Red"]CANNOT LINK EXECUTABLE: cannot locate symbol "__register_atfork" referenced by "/system/bin/toolbox"...[/COLOR][/B]
page record for 0xb6ef304c was not found (block_size=32)
- Creating paths
- Removing old files

2- Patching sepolicy

check_zero_def "" "LD_LIBRARY_PATH=$SYSTEMLIB
/su/bin/sukernel --cpio-add /sutmp/ramdisk
/sutmp/ramdisk [B][COLOR="Blue"]644[/COLOR][/B] sepolicy /sutmp/sepolicy_patched"

-rw-rw-rw- 1 root root 2279160 Jan 21 17:19 ramdisk
-rw-rw-rw- 1 root root 1199423 Jan 21 17:19 ramdisk.packed
-rw-rw-rw- 1 root root 240961 Jan 21 17:19 sepolicy
[COLOR="Red"]-rw-------[/COLOR] 1 root root 243577 Jan 21 17:19 sepolicy_patched

Neither of the above two affect anything, as far as I can see, just mentioning it