Size of phone

[_DW_ 628]

@B.X I guess it really depends on your hand size to get the correct fit.  Always good when a manufacturer offers a rang of sizes.

[EskeRahn 5,471]

5 hours ago, B.X said:

Unfortunately they put empty space on both sides

They could have widened the whole thing BUT if so, they would need to keep the lower corners without keys (Similar to what BB did on the Priv), as corner would for most people be causing issues when they reach for the middle and, corner keys would also be hard to fold the thumb to reach.

I HOPE (though doubt) that this will become such a huge success, so they can make a Pro2- and Pro2+ with identical logical specs, and scaled down with about 10% respectively up by 5-10%. (The same way SonyEricsson did many years ago with their keyboard-less variants of the Xperia (Neo) Pro, that is the Ray, Neo and Arc trio, to my knowledge that was the last time someone released a flagship with identical specs, only different in physical sizes, since then they have used the communist idea that we are all so equal so we only need the same size. BTW The Arc was back then considered ridiculously huge - in 2019 it would be a 'super compact'... )

[_DW_ 628]

2 hours ago, EskeRahn said:

The same way SonyEricsson did many years ago with their keyboard-less variants of the Xperia (Neo) Pro, that is the Ray, Neo and Arc trio, to my knowledge that was the last time someone released a flagship with identical specs, only different in physical sizes, since then they have used the communist idea that we are all so equal so we only need the same size. BTW The Arc was back then considered ridiculously huge - in 2019 it would be a 'super compact'... 

Yes companies really need to do this more.  TBH it's simple design the small one then the 2 larger sizes come free just put bigger screens in 😄.  That wouldn't work with a keyboard phone though you would expect the keyboard to be redesigned.

[david 929]

6 hours ago, VaZso said:

Do these files have different case of characters (lower case and capitals in the name) which are different in these files?

Under Linux, those types of files are treated as different, but under Windows, they are the same (duplicate names).

You may try to modify it under Linux.

I considered that build.prop might have different cases for the 2 copies.  Windows apps that work with tar aren't the most robust.  Most of them didn't even show the duplicate when browsing the .tar (without extracting).  Also, it appears there is a way to add true duplicates to tar files, so that could have been done too by TWRP.  

Since my data should be intact if i reflash the firmware, I'm just going to do that.  I'll take a nandroid backup of all existing partitions first, just in case the new one doesn't boot.  If I have to revert back to the existing system, I'll try transferring the tar to linux and seeing how it looks there.

Note to self:  Always make sure you have TWRP installed and, even more importantly, always make sure you have USB debugging enabled and can access your android devices via ADB.  Recheck this periodically, since system updates can reset it.  I might look into some automated (Tasker, etc) way to check whether this is set, and alert me if not.

[VaZso 1,998]

3 hours ago, david said:

If I have to revert back to the existing system, I'll try transferring the tar to linux and seeing how it looks there.

If you are not using Linux regularly, a Knoppix may be a fast solution to try this.
(It can be copied to a bootable USB device, then you can boot into a Linux which has usable GUI and I think it has all the tools needed.)

Edited November 12, 2019 by VaZso

[EskeRahn 5,471]

@VaZso , @_DW_ (I moved some dialogue to the repairability thread, where it fits better than a thread on size)

[david 929]

9 hours ago, VaZso said:

If you are not using Linux regularly, a Knoppix may be a fast solution to try this.
(It can be copied to a bootable USB device, then you can boot into a Linux which has usable GUI and I think it has all the tools needed.)

I have Linux virtual machines that I can use, but thanks for the help.

I decided to keep trying to get it working without flashing the stock firmware over the top, partly in an effort to see what could be done if I get stuck in the future.  I'm still fighting it and will fight it a while longer before doing the firmware flash.

I'll say it again:  Be very very careful if you decide to mess with changing resolutions.  On the Pro1, it might not be a big deal.  I guess it depends on whether their launcher was made to handle multiple resolution devices.  It seems like every bit of Samsung software on this tablet was not! LOL

[david 929]

45 minutes ago, david said:

I have Linux virtual machines that I can use, but thanks for the help.

I decided to keep trying to get it working without flashing the stock firmware over the top, partly in an effort to see what could be done if I get stuck in the future.  I'm still fighting it and will fight it a while longer before doing the firmware flash.

I'll say it again:  Be very very careful if you decide to mess with changing resolutions.  On the Pro1, it might not be a big deal.  I guess it depends on whether their launcher was made to handle multiple resolution devices.  It seems like every bit of Samsung software on this tablet was not! LOL

Okay, after *many* hours of fighting with this, I finally fixed the tablet.  That was quite the challenge.  If anyone wants more details, feel free to ask, but I'll try to explain what I tried that failed and then what finally worked.

First off, I had a stock ROM, with Android 5.1.1, that was rooted before I began all this fun.  This is a Samsung Galaxy Note 10.1 2014 Edition (SM-P600 = Wifi version, not cellular).  The method I used to root this previously is this:

https://www.droidviews.com/root-galaxy-note-10-1-sm-p600-and-install-twrp-on-it/

I did flash TWRP 3.3.1.0 and then flashed 3.3.0.0 (to try to overcome something that wasn't working, but ended up being user confusion) as part of all this too.

I was going to flash a supposedly stock version of the firmware I found online, but I did read at least one account of someone whose resolution was messed up and reflashing the firmware somehow did not fix the resolution.  I also figured I'd try some other less drastic things before flashing the firmware, since I couldn't be sure it would identical to what I already had and who knows what other issues I might have caused.

And to recap how I got into this mess...  I used Easy DPI Changer [ROOT] (https://play.google.com/store/apps/details?id=com.chornerman.easydpichanger&hl=en_US) and changed the resolution from 2560x1600 to 2360x1400 (200 pixels off each dimension).  All the Samsung bloatware and custom apps failed as a result of this, including the launcher, so I was stuck with no way to run any apps when booted into Android.

Issues:

• I couldn't connect to the device with ADB.  At first it was even when I was in recovery.  However, that turned out to be because I forgot to run my command window in Windows as administrator.  Since I couldn't connect to the device with ADB, I couldn't just use "adb shell wm size reset".  That would have been very easy if I could have done that.  This command can't be run from the ADB shell when in recovery, because the wm command doesn't exist and that whole window manager system isn't part of recovery -- it is part of Android.  I couldn't run ADB shell when booted into Android, because the device was showing as unauthorized with "adb devices".  I thought that was because I didn't have USB debugging enabled, but it turns out I did have it enabled.  I just hadn't told the tablet to always trust my laptop when I originally connected to it.  The pop-up where you allow the connection couldn't pop-up in the tablet due to the screen resolution issue.  So ADB was out of the picture, even though I wasted a bunch of time trying to get it working.
• I couldn't originally access the build.prop file in /system on the device in TWRP.  /system was showing as only having a /bin subfolder and nothing else.  I did manage to take a nandroid backup of /system with TWRP, saved it to an SD card, and messed around with it on Windows.  However, due to the way nandroid backups build the tar files, I couldn't reliably modify the build.prop and put it back into the backup files without causing other issues.  I also had trouble restoring the backup, but that seemed to be caused by needing to reboot into recovery when inserting the SD card.  It didn't want to give the proper restore options if I hot inserted it while in TWRP.  What the real problem was, with accessing /system, is that I'm not used to TWRP (I use ClockworkMod on my phone) and didn't realize how to properly mount the /system partition.  I would go into the Mount screen in TWRP and check the box for /system and then click a button for Mount as USB (which would have allowed it to show in Windows, as it turns out, if the laptop was trusted, I think), but then I'd unmount as USB and clear the check box, as there was no way to go back to the regular TWRP screens while in that USB mounted state.  Although it doesn't give you any visual feedback that something has happened, you simply have to check the box next to /system and that does mount it for use in TWRP.  That took a *long* time to figure out and was critical to me being able to finally fix things.

Tried and failed to fix the issue:

• Safe Mode - Resolution was still modified and launcher still crashed.
• As mentioned above, trying to modify build.prop to either enable USB debugging or set the resolution back to the max resolution from a nandroid backup didn't work.  It got in a boot loop, since the permissions on the file weren't correct once /system was restored, so I had to restore the original backup.  Note:  This is why you always make an extra copy and keep one untouched version of files. :-)
• Once I could see the build.prop in TWRP, I was able to edit it in the vi editor through the TWRP terminal app, but apparently, with this version of android or because of something Samsung did, setting the resolution in build.prop didn't work, nor did enabling USB debugging work (for all I know, it did re-enable it, since it was already enabled, but I still couldn't connect with ADB due to the authorization issue mentioned earlier).  The lines added were:
  • persist.service.adb.enable=1                                                    
    persist.service.debuggable=1
    persist.sys.usb.config=mtp,adb
  • persist.dash.max.rep.resolution=2560*1600
• Tried creating a flashable zip that contained a modified build.prop in my /system nandroid backup, using these instructions:  https://www.droidviews.com/create-flashable-zip-cwmtwrp-backup/  Can't remember if it wouldn't flash it or if it just didn't do anything.  I think it failed to flash it.
• Tried to find a shell script that runs on boot that would allow me to run commands to reset the resolution or enable usb debugging (in case it wasn't set).  Samsung and Google have closed all these loopholes, so I wasn't able to do that.  I only found one that looked promising, but it isn't run in this device:  /system/etc/install-recovery.sh

Final solution, albeit with some failures first:

• Used TWRP to flash initd_any_stock_v1.3.zip from here:  https://forum.xda-developers.com/android/software-hacking/script-zip-init-d-enabler-stock-kernel-t3347724  This did install properly, as once it booted into android, I was able to see its log file that is generated from its script in /system/etc/init.d once I went back into TWRP's terminal.  This allowed me to run any script I wanted on android startup by putting it in the /system/etc/init.d directory.
• However, running "wm size reset" from inside a script didn't fix the problem.  I finally had to create a script that calls a script so that I could log the output and find out what was failing and why.  The error was: "error type 2.  Can't connect to window manager;  is the system running?"
• Googling around, it seemed like it needed to be run as root.  I wasn't sure if it should run as root, since the device is rooted, or if I needed to use "su" to run the command.  So I modified it to "su -c "wm size reset"".  That failed with the same error message.
• I started wondering if running this when the system first boots was too early and maybe the window manager wasn't initialized and running yet.  I was also considering using this mechanism to enable usb debugging (because I still wasn't sure if that was enabled), using "setprop persist.service.adb.enable 1".  
• I started down the path of how to delay running the command until the UI had come up fully.  I thought maybe I'd have to create some ugly cron job that would run as root to run the "wm size reset" command.
• I then decided to try something simple.  I put a "sleep 60" before my "su -c "wm size reset"" command in my shell script.  I wasn't sure if this would block the system from coming up or how things were threaded, but I figured it was worth a try.  The system did its normal thing of going through the various Samsung logos and then shifting the final logo when the screen resolution changed due to the begin set smaller than max, and the same errors popped up saying various components were crashing.  A minute after startup, the screen resolution changed!!  But oddly enough, it got even smaller!!  It almost seemed like it lost another 200 to 400 pixels of the right and bottom of the area being displayed!  My first thought was that I'd have to change it to "wm size 2560x1600" instead of "wm size reset".  But at least I knew it was able to run if I just gave it more time before executing the command.
• However, when I dismissed the error message that was on the screen from one of the components that had failed to startup properly, I was brought into my lock screen at full resolution!  I was able to enter my unlock code and get into Android finally!  The background color of the launcher was messed up, and some weather app (that I can't even find on the tablet) popped up that it crashed, but I was able to use my apps just fine!  After another reboot, the launcher background color was back to normal and no more apps reported crashing.
• The other thing that popped up was the dialog to ask if I wanted to authorize the laptop for the USB connection.  I told it to always trust the laptop.  This also allowed the tablet to show as the 2 storage devices in Windows Explorer (one for the internal /data partition (/data/media/0) and one for the external SD card).  That had always failed when the tablet was in the messed up state and without authorization.  It also doesn't show the storage devices unless you unlock the lock screen, and since the UI was messed up, I couldn't do that before.  I also tested ADB to the tablet with the tablet booted into android and that works now too, after that authorization.  USB debugging was already enabled from when I had rooted it.
• One last thing.  Although I can now adb to the tablet when in Android, in order to run "su" once in "adb shell", I had to grant permission with SuperSU.  That pop-up wouldn't have been accessible to me if my screen wasn't working.  So not only should you enable usb debugging and test adb to connect to your device and get into the shell, but you should also run "su" in the shell, so that you'll be prompted to allow the shell to run as su and you can answer appropriately so that it always allows it going forward.  Maybe there is some way to set SuperSU from the TWRP terminal to allow certain apps to run as su, but that would be another frustrating thing to try to do.  And although I didn't need to run su from the adb shell for this solution, there may be other scenarios where it is needed or preferred, vs mucking around in TWRP's terminal and typing on a giant, lousy virtual keyboard. :-)

That's it for my adventure.  I thought maybe changing the resolution would cause things to display oddly.  I didn't realize it could put me in this type of soft bricked state.  Lesson learned. :-)

[EskeRahn 5,471]

3 hours ago, david said:

That's it for my adventure.  I thought maybe changing the resolution would cause things to display oddly.  I didn't realize it could put me in this type of soft bricked state.  Lesson learned. 🙂

TLDR, but thanks for the warning and detailed info, if someone else get into similar predicaments  with the Pro1

[divstar 164]

Honestly.. if it was bigger I would have reconsidered buying it, too. I loved my HP Veer. If only it's battery and specs were up to date and the OS more recent.

If a Pro1mini was to be released I might get it in addition to the Pro1.