Swype Beta / Added /system Notifications didn't affect update - Atrix 4G General

Just wanted to pass this along as I asked the question but no one answered it...
I was one of the people selected to test the 4.1.57 update. I had added several notification sounds to my /system file, as well as changed to the beta version of Swype.
For Swype, I used RootExplorer and changed the names of the stock Swype files to .bak. This allowed me to install the beta version of Swype (that I was also signed up to test previously).
Anyway, I got sick of the update notification popping up on my phone so I just ran the update. I did lose root, as everyone knows. However, the custom sounds I added to the /system folder, and the beta version of Swype, are still there and still work, and had no affect on the update. My version in the About Phone page reads "Version.4.1.57.MB860.ATT.en.US" so I did get the update successfully.
Yes, it sucks that root is lost (hopefully temporarily) but it is good to know that you can install sounds and Swype and other apps that need root (to install but not to use) prior to updating and they'll still work after.

Related

[Q] Swype Beta on Droid X

Please note: I'm not asking for the APK here.
I had an Evo and signed up for the swype beta and was accepted into the program, I returned my evo and got a droid x which comes with swype installed.
As you all know, swype has continually been updated since the version available on my phone. I'm in the beta program and able to download/login to the swype site with my beta account, i've successfully installed the swype beta before on my evo using my credentials.
Here's my problem:
with the latest installer(1.1.5151 i think) it's telling me my current version isn't properly licensed, and is asking me to disable swype to generate a license, because it comes with my droid x i'm not able to disable the keyboard.
even if i have to root is there a way i can disable or remove the built in swype keyboard so i can install the beta?
Are you rooted? If so you can get rid of the swype.apk, but you also have to find the swype library file, which I don't know the exact name or location of off the top of my head.
milan616 said:
Are you rooted? If so you can get rid of the swype.apk, but you also have to find the swype library file, which I don't know the exact name or location of off the top of my head.
Click to expand...
Click to collapse
/system/lib/libswype(something something).so as I recall
hope this helps you out:
posted by grooves12 in the swype forums
Tutorial: Installing Beta Swype on Droid X (or other pre-installed devices)
First, your Droid X must be rooted. There is plenty of info out there on how to accomplish this.
Get a root file manager (I use root explorer)
1. Change your default input method to anything other than Swype.
2. Mount file system as R/W
3. Delete (or move/rename) \system\app\swype.apk
4. Delete (or move/rename) \data\dalvik-cache\[email protected]@[email protected]
5. Delete (or move/rename) \system\lib\libSwypeCore.so
6. Reboot
7. Download and Run the latest Swype Beta installer
8. ENJOY!
I hold no responsibility if you screw up your system, and recommend you make a backup before attempting this, but, the above steps worked perfectly for me, and I am now running the latest Swype beta on my X.
These steps should also work on other models that come pre-installed with Swype from the factory, but I don't have another one to test, so have no way of being sure. If anyone tries it, let me know if it works for you!
Last edited by grooves12; 12-08-2010 at 1:32 PM.
Nodren said:
is there a way i can disable or remove the built in swype keyboard so i can install the beta?
Click to expand...
Click to collapse
Why do you want to use the beta instead of the stock Swype app?
The beta does seem to work better
One notable feature in the beta is that you can double tap words to pop up a list of other possible words you meant to use instead
Yes, the new Swype is better than stock: larger keys, better recognition and, as you note, double tap brings up alternate word choices. But no need to mess with the beta registration, authentication, etc. You can update to Swype 2.15 here.

How To Switch Back to Newer Swype Beta After 3.70 Update

I apologize if this has been posted before, but I have been googling for days and searching on this forum for the answer and couldn't find it.
After Sprint updated the Evo to 3.70, it came with an older version of swype that wasn't as nice as the newest Swype betas (like the recent March 2011beta). Hidden word warnings popping up all over the places was frustrating as hell.
Here is how to switch to the newest version of swype beta.
1- Uninstall the swype beta and installer if you currently have them installed.
2- Use Root Explorer (or similar) and delete or rename "/system/app/Swype.apk" and "/system/lib/libSwypecore.so" (I simply changed the extention to .bak in case I needed them again).
3- Reboot your phone
4- Go to the Swype Beta website and download the newest swype beta installer as per your original beta email instructions.
Doing this, I got the newest Swype Beta (March 2011) running on my Evo running 3.70. Its running very well and I haven't run into any problems whatsoever. Beware that this isn't supported by Swype, but this is their instructions. Finally, no more hidden word notifications!
Original Swype Forum Post
Here's the post that MultiDev mentions:
http://forum.swype.com/showthread.p...install-Swype-Swype-PreLoad-Production-Device
Gonna try this now....Fingers crossed!
Update: Works great! Running Swype 2.29.71.20186.t100 on my HTC Evo 3.70.651.1 . I can already tell the difference in usability with Swype...seems a lot smoother and faster to me. The reason I wanted the latest beta was to fix the ridiculous problem with auto inserting words from dictionary (and then telling you about how you can delete the word (but it doesn't actually work) via a popup) thing is fixed, that's really all I care about.
Instructions for Installing Swype BETA 3.0 on Sprint Evo Stock Gingerbread 2.3.3 ROM
This same method from above works with Swype Beta 3 which was recently released:
https://forum.swype.com/showthread.php?3700
Here are the steps I took to get my Sprint Evo running the Stock Gingerbread update working with the new Swype Beta 3:
(This method was used previously on my Sprint Evo running Stock 2.2 Froyo Rooted, AND on my Sprint Evo after the 2.3.3 GB update. FYI I clean installed xHausx_supersonic_4.22.651.2_deodexed_rooted-signed to retain my Root privileges)
1. Uninstall Swype.apk using program of choice (I used Ti Backup; apk is located here: /system/app/Swype.apk) (tip: you do not have to unselect Swype as your current input method)
2. Remove this file: /system/lib/libSwypecore.so (I used Root Explorer for this)
3. Reboot
4. Download/install Swype Installer.apk
5. Sign in to DL actual Swype.apk
6. Choose version of Swype to install (I picked English/Spanish Beta)
7. Go through Swype Installer process (IE: Install, generate license, select Swype as input method)
8. Done!
References here:
http://forum.swype.com/showthread.p...install-Swype-Swype-PreLoad-Production-Device
http://androidforums.com/evo-4g-all...gingerbread-copy-paste-popup.html#post2828288
Swype Beta v3.0 Thread:
https://forum.swype.com/showthread.php?3700
Hope this helps someone!
This isn't possible with an unrooted phone, correct? I don't wanna mess anything up.
Ant918 said:
This isn't possible with an unrooted phone, correct? I don't wanna mess anything up.
Click to expand...
Click to collapse
That is correct, you have to be rooted to delete the swype system files.
Ok thanks, guess ill have to wait for Swype dev's to come up with their own fix
Ant918 said:
Ok thanks, guess ill have to wait for Swype dev's to come up with their own fix
Click to expand...
Click to collapse
Unfortunately, Swype does not directly update OEM installs like the one on the Evo. They simply pass on their updates to the OEM (HTC, in the case of the Evo) and its up to the OEM/carrior to bundle it into their next software update. Its up to HTC/Sprint if they want to bundle newer versions or not and decide when that update is released.
Swype only updates their beta directly and you needed to be rooted to install the beta on the Evo.

4.5.602 .apk`s that can be removed.

I have seen all the threads about apk`s that can be renamed or removed froyo 2.2 on a few different websites.
could someone make a current one for GingerBread 4.5.602 now that we have a working root?
would very much appreciate it as i dont think all the files are the same as they used to be in froyo 2.2
there are so many threads on what to remove and what not to remove from all around...
no one has made a thread about .apk`s for 4.5.602....so someone has a chance to be the first.
make a new thread or use this one i dont care...in the end i just want to know what we can remove and what we cant.
the names that root uninstaller shows would be great if someone could cross refrence to what the actual .apk is.
thanks
Bloatware .602 APk's that can be removed...
I would be THRILLED to be able to get a list of bloatware .602 APk's that can be removed without affecting the OS or any 'tangential' functionality. I prefer to stick with the rooted stock .602 ROM...
Anybody have any ideas?
a first-must-know
* preventing subsequent OTA "upgrades"
lest they kill this new root
How to stop OTA upgrades
I use Titanium Backup Pro - it's not perfect, but darn good. I started getting the OTA upgrade from Verison in a popup message, with a timer on it. I could click yes to do the upgrade or no to not do it, and the time was counting down in seconds at which point when it reached 0 it was going to do the upgrade if it did not get a response. I got this repeatedly.
I saw another thread that explained that if you 'freeze' (within Titanium Backup Pro) the application named "Updater 2.3.3" then this would not happen any more. That resolved my issue. This did not have any effect on the upgrades for which I got notices and could check on from the Amazon App Market or the Google Marketplace.
What bloatware can be removed? I have removed "City ID" and it has not seemed to affect me.... anybody know what else can be removed safely?
When I first looked around on the internet (and I'm good at doing search) I didn't find any lists of applications you can "freeze" (rename or move to another folder until you need them to update) specific to Droid X Gingerbread. Then while researching other issues I bumped into a fairly complete list (hope mods here don't mind me posting link!)
http://androidforums.com/droid-x-all-things-root/319383-apks-files-safe-remove-gingerbread-gingerblur.html
One issue I've run into is that if you use Titanium Pro you have to translate the actual .apk file name into what it displays. The Titanium devs should add the underlying apk file name to their list. I just upgraded to Pro because I've been using the product for backup/restore and was tired of renaming .apks to .apk.bak to freeze them. I like being able to have a freeze list I can save for the next time I upgrade. I suppose I should learn a bit more linux and create a script but...

How to prevent updates?

Ok, they keep updating and breaking root. I hear droidwall will block it.
But what is the name I should be blocking?
Or is there a better way to stop auto updating?
Delete OTACERTS.zip in system/etc/security. You must enable r/w and have root.
When I did It, it downloaded the update in front of me but didn't update. Then I deleted the update. Now i'm still on 6.2.1 and Loving It.
Molinari said:
Ok, they keep updating and breaking root. I hear droidwall will block it.
But what is the name I should be blocking?
Or is there a better way to stop auto updating?
Click to expand...
Click to collapse
I did the otacerts.zip thing mentioned above (moved to sdcard and renamed to otacerts.bak).
However, just to be safe I am also using droidwall. With droidwall, I started out by blocking everything (default) and then unblocked things when they would not work (use the log to see what is being blocked). Be sure to actually enable the blocking and the logs (they are off by default). Some things you can be unblocked ahead of time like Market and Browser. The only potential issue with using droidblocker is that whatever is used for the OTA update might also be used by something else that needs to be unblocked.
mark_a_l said:
I did the otacerts.zip thing mentioned above (moved to sdcard and renamed to otacerts.bak).
However, just to be safe I am also using droidwall. With droidwall, I started out by blocking everything (default) and then unblocked things when they would not work (use the log to see what is being blocked). Be sure to actually enable the blocking and the logs (they are off by default). Some things you can be unblocked ahead of time like Market and Browser. The only potential issue with using droidblocker is that whatever is used for the OTA update might also be used by something else that needs to be unblocked.
Click to expand...
Click to collapse
Droidwall Doesnt work, I tried that on the 6.1 to 6.2 update because I did not want to risk a potential update. That was before we knew of the ota updates.
iroctheworld said:
Droidwall Doesnt work, I tried that on the 6.1 to 6.2 update because I did not want to risk a potential update. That was before we knew of the ota updates.
Click to expand...
Click to collapse
What were you blocking? I've only got about 6 things on my white list (not blocked). Half are market related. In any case even if it doesn't work for OTA updates, I find some apps to be a bit too 'chatty' (looking at the logs). So it does work at blocking 'unnecessary' wifi traffic.
Thanks for the rename tip!
I am still avoiding the 6.2.2 update (only time can tell, last time mine was updated about 1 week after the first posting about forced updates ...)
I am running the rooted version of 6.2.1. I flashed this after losing root from the 6.2.1 forced update.
This time I only did two "mods" for protection -
(1) un-register from Amazon (actually I never register during ROM installation)
(2) use Droidwall
I dunno which one will make me survive the forced update, but I suspect it may / will be #(1).
I only allow a few things to go through Droidwall, most of them are 3rd party apps' names. The only two additional processes necessary for normal functions are:
(1) downloads, media storage, DRM protected content storage, download manager (needed for Market downloads)
(2) search (for Google search)
The one I always worry about in Droidwall is obviously #(1). I certainly do not let things like Amazon device client platform (ADCP) to go through!
This is just my Droidwall setup. People using other apps may need to allow other Android processes through therefore I cannot guarantee Amazon update won't sneak through that way.
I only know about the otacerts.zip when I revisited the forum yesterday afte reading elsewhere about the new OTA update. This time I won't modify this file on purpose.
(fingers crossed for me, I am not out of the woods yet)
P.S. Feb 2nd and I am still clean, looks like I dodged it!

qemu.hw.mainkeys=1 works for everyone EXCEPT ME

Ever since getting my Razr Maxx HD (XT926) three months ago I've been trying to get rid of the Navigation Bar on the bottom of the screen. I use Button Savior so I'm fine with having the NavBar controls disappear.
Among the most reliable remedies seemed to be upgrading to 4.1.2, at which point many people said that you could simply add the line "qemu.hw.mainkeys=1" to the end of your build.prop file in /system, reboot, and *poof* the NavBar would be gone. My phone, which I bought used, was running a leaked 4.1.1 so, once root for OTA 4.1.2 was discovered, I downgraded to 4.0.4, did the updates to that, then took the OTA upgrade to 4.1.1 (no problem), then took the OTA upgrade to 4.1.2 (no problem). So now I had the latest JB version offered for Verizon XT926 in the US. I know that I'd wiped data at least once along the way. The SafeStrap installation that I used to have was gone, as I expected. I assumed that my phone was as stock as it could be and thus ready for the build.prop edit.
I used the new procedure to root my XT926. At that point all I did was to download and install Root Explorer (needed to do the build.prop edit) and Button Savior (needed for navigation once NavBar was gone). In Root Explorer I navigated to /system, made it R/W, opened build.prop in the stock text editor, added qemu.hw.mainkeys=1 at the end, saved (which backed up the older version as expected), and rebooted.
The first thing I get when my phone boots up is the "SystemUI has crashed" error message. My NavBar is gone but so is my System Bar (a/k/a Notification Bar), which I need and want to be visible. I've read a TON about this and I'm pretty sure I've followed the instructions. Why is this not working for me?
I am just not smart enough to decompile and edit my framework-res.apk file (or whatever the name is) so I'm stuck trying to make the build.prop edit work. What could I be doing wrong?
(also, if I use one of the apps like FullScreen or BottomBar they produce the EXACT SAME result -- SystemUI crashes, NavBar disappears but so does System Bar).
cant help
it works for me as experted
Are you positive you entered it correctly?
Sent from my JokerMATRIX HD MAXX
deeje00 said:
Are you positive you entered it correctly?
Sent from my JokerMATRIX HD MAXX
Click to expand...
Click to collapse
He also tried an app which writes the line to the build.prop and got same results.
AFAIK I had crashes on ICS but since I'm on JB 4.1.2 I never had any issues...
Sent from my XT925 using xda app-developers app
Yes, the edit is entered correctly. I've checked that more times than you can imagine. And I've tried nearly every variation that's been suggested anywhere: with spaces before and after the "=", adding the line ending with "0" first then rebooting then changing the end to "1" then rebooting, putting an empty line at the end of build.prop before adding the edit. No change. Is there any history of an app interfering with this edit? I don't have anything exotic installed I don't think but I use a third party launcher (Go Launcher EX) and then a variety of apps, mostly audio/video, social media and a few basic games. I believe that changes to build.prop take place "below" that kind of activity, though, right? And besides, I made the edit before I installed any of that stuff. I may try a hard reset or something like that but if this works for everyone else then I must just be missing something.
I have had the exact same issue and done the same troubleshooting...sucks!
did you happen to check file properties after you saved, i remember back in the early days of Android if you edited a file, you had to change the properties back to the defaults, not sure if that is still the case, but worth a look.
It can't be done on any stock via build.prop only, and framework edits require a deodexed rom.
I recommend you install CM10 or 10.1. If you prefer safestrap over CWM, then you can use CM10, but without a camera. Fullscreen toggle works perfectly, and I'm able to use PDroid : )
I suppose I should be glad that at least *one* other person is having this problem. Means it's slightly less likely that I'm just incompetent.
As for changing file properties, I didn't change any properties to do the edit other than making /system "RW" in order to be able to edit the file. Could someone tell me what the default values are for build.prop? The most recent edit I've made always shows up correctly when I go back into build.prop, by the way, so I know I'm actually changing the file.
If a rooted stock 4.1.2 can't hide the NavBar with a build.prop edit then this is the first I've read about it, and I've read just about everything that I can find on this subject (including translations of non-English discussions, just in case I could get a new lead from them). Not saying that's not true, just not consistent with what I've read so far.
I'd love to install a CM ROM on my XT926. I've admired Cyanogenmod since I first started fiddling with my Nook Color some years ago. Their crew does some spectacular work. But -- no camera? No Bluetooth? Sometimes wifi or phone call problems? That's too much lost functionality for me. If those remaining few obstacles are someday overcome I'll be all over it though.
ONE LAST QUESTION -- I assumed that, if I "scrubbed" my phone down to the lowest level possible (wipe cache, wipe dalvic, wipe data) I would eliminate whatever weird impediment I have to getting the build.prop edit to work. Is there something else I can do to wipe the phone even MORE thoroughly?
The permissions are RW-R-R, I have had the issue with stock and custom roms (running Foot Through the Floor right now). I wasn't surprised when it didn't work with stock (silly Moto) and I was a little surprised when it didn't work with and of the custom roms I tried, I have no doubt it would work in CM.
I tried it out, it works but you need to reboot after edit, I hot booted and nothing changed, full reboot and it works. hope it helps you.
Just in case this makes the difference, can you tell me what distinguishes a "hot boot" from a "full reboot"?
Having issues myself. Have 4.1.2 rooted, RAZR HD. Added the line above to build . prop with "=0" first shutdown, started back up. Then changed to "=1" saved, shutdown and started back up. System UI FC's.
Wonder if it matters what launcher is being used. I am on GO Launcher. I say this since on home screen I see the GO Launcher menu show up just below bottom of my wallpaper but behind it. I can swipe up to bring up full menu but it is weird how it comes up in background on its own.
Anyone get it to work with GO Launcher?
Sent from my DROID RAZR HD using xda app-developers app
---------- Post added at 10:56 AM ---------- Previous post was at 10:54 AM ----------
Oh and does it matter where in build.prop the line goes? I just added to bottom. Thx.
Sent from my DROID RAZR HD using xda app-developers app
---------- Post added at 11:29 AM ---------- Previous post was at 10:56 AM ----------
lesdense said:
Yes, the edit is entered correctly. I've checked that more times than you can imagine. And I've tried nearly every variation that's been suggested anywhere: with spaces before and after the "=", adding the line ending with "0" first then rebooting then changing the end to "1" then rebooting, putting an empty line at the end of build.prop before adding the edit. No change. Is there any history of an app interfering with this edit? I don't have anything exotic installed I don't think but I use a third party launcher (Go Launcher EX) and then a variety of apps, mostly audio/video, social media and a few basic games. I believe that changes to build.prop take place "below" that kind of activity, though, right? And besides, I made the edit before I installed any of that stuff. I may try a hard reset or something like that but if this works for everyone else then I must just be missing something.
Click to expand...
Click to collapse
I just noticed this (missed it first scan through) that you use Go Launcher as well. I do also and am having same issue. I am going to try switching to Apex, Nova or other to see if that is the culprit. If so, I can most likely get used to another custom launcher to gain the extra space.
BUT if anyone doesn't have issues AND is using Go Launcher, please let us know so we can rule that out.
Thanks
I use nova pro and have the issues.
Sent from a non-apple device.
coolloser said:
I use nova pro and have the issues.
Sent from a non-apple device.
Click to expand...
Click to collapse
I just tried Apex Launcher and had same FC issue. So guess it isn't specific to any of the launchers (was a long shot anyway). This is just really weird. Some folks swear they have it running on stock 4.1.2 (OTA update) rooted, but many of us have the same and can't get it to work.
I saw one thread where someone mentioned you needed to make sure everything is stock, meaning using TB to unfreeze anything you had frozen, and then give it a go. Problem is I'll want to refreeze much of that bloatware from VZW so not sure if that helps or not.
So frustrating......
At this stage in the trail and error I wonder what other variables could be the key. It's not the version (4.1.2). It's not launcher (problems with Go, Apex and Nova plus the stock launcher). Making everything stock didn't help me -- I flashed a brand new version of 4.1.2, installed ONLY Button Savior (for navigation) and Root Explorer (to edit build.prop). Same problems as usual. I assume it's not the rooting utility as I believe only one exists.
OK, how about some weirder ideas. Has everyone done the build.prop edit with Root Explorer? Maybe there's a flaw in that tool. I just tried editing the build.prop to put IN the qemu.hw.mainkeys=1 line, then temporarily suspended root with VooDoo, then rebooted to see if it would behave if it thought it wasn't rooted. Same result. Maybe the guy saying you can't make this work on rooted stock ROMs was right Still, I'll keep looking, and sharing.
lesdense said:
At this stage in the trail and error I wonder what other variables could be the key. It's not the version (4.1.2). It's not launcher (problems with Go, Apex and Nova plus the stock launcher). Making everything stock didn't help me -- I flashed a brand new version of 4.1.2, installed ONLY Button Savior (for navigation) and Root Explorer (to edit build.prop). Same problems as usual. I assume it's not the rooting utility as I believe only one exists.
OK, how about some weirder ideas. Has everyone done the build.prop edit with Root Explorer? Maybe there's a flaw in that tool. I just tried editing the build.prop to put IN the qemu.hw.mainkeys=1 line, then temporarily suspended root with VooDoo, then rebooted to see if it would behave if it thought it wasn't rooted. Same result. Maybe the guy saying you can't make this work on rooted stock ROMs was right Still, I'll keep looking, and sharing.
Click to expand...
Click to collapse
Root Explorer is what I used.
For the other guy having trouble, it hasn't been mentioned yet; did you set the owner and group for the file to root? If the file was ever stored on the sdcard or pushed there then moved, those permissions might make a difference as well. Its a good security measure in the case that it isn't relevant in any case... don't want a wild website writing to your build.prop file, for example.
PantsDownJedi said:
Root Explorer is what I used.
For the other guy having trouble, it hasn't been mentioned yet; did you set the owner and group for the file to root? If the file was ever stored on the sdcard or pushed there then moved, those permissions might make a difference as well. Its a good security measure in the case that it isn't relevant in any case... don't want a wild website writing to your build.prop file, for example.
Click to expand...
Click to collapse
I used ES File Explorer (and then you have to use Root Explorer menu option to set r/w prior to opening build.prop).
Regarding the rest of the post above. Not sure what the question is. I never did anything to the build.prop file other than set ES File Explorer to r/w on everything, then edited the build.prop file, saved, checked to ensure it was edited right, then rebooted. So the 'file' has never been anywhere other than in /system. When I check the properties on the build.prop file I see rw- r-- r-- (this the same whether or not /system is set to RW or just RO). I believe these are correct (default) settings, but let me know if that is not correct.
Anyone out there that has this working on Stock 4.1.2 it would be nice to know more (i.e. is 4.1.2 the OTA or leaked version, did they use motochopper root method (only one I thought), persmissions on file, where did they place the qemu line in the file, etc, etc).
---------- Post added at 11:33 AM ---------- Previous post was at 11:21 AM ----------
PantsDownJedi said:
Root Explorer is what I used.
For the other guy having trouble, it hasn't been mentioned yet; did you set the owner and group for the file to root? If the file was ever stored on the sdcard or pushed there then moved, those permissions might make a difference as well. Its a good security measure in the case that it isn't relevant in any case... don't want a wild website writing to your build.prop file, for example.
Click to expand...
Click to collapse
BTW... anyone look into testing the framework-res.apk option? Sounds in-depth and much more work (not to mention chance of screwing things up). It would be new to me to decompile, etc, etc, but am not scared to try, just thought I would ask if anyone else already has. Also, not sure if that option is for the 4.1.2 OTA version (verizon in my case).
Thanks.
surfmly said:
I used ES File Explorer (and then you have to use Root Explorer menu option to set r/w prior to opening build.prop).
Regarding the rest of the post above. Not sure what the question is. I never did anything to the build.prop file other than set ES File Explorer to r/w on everything, then edited the build.prop file, saved, checked to ensure it was edited right, then rebooted. So the 'file' has never been anywhere other than in /system. When I check the properties on the build.prop file I see rw- r-- r-- (this the same whether or not /system is set to RW or just RO). I believe these are correct (default) settings, but let me know if that is not correct.
Anyone out there that has this working on Stock 4.1.2 it would be nice to know more (i.e. is 4.1.2 the OTA or leaked version, did they use motochopper root method (only one I thought), persmissions on file, where did they place the qemu line in the file, etc, etc).
---------- Post added at 11:33 AM ---------- Previous post was at 11:21 AM ----------
BTW... anyone look into testing the framework-res.apk option? Sounds in-depth and much more work (not to mention chance of screwing things up). It would be new to me to decompile, etc, etc, but am not scared to try, just thought I would ask if anyone else already has. Also, not sure if that option is for the 4.1.2 OTA version (verizon in my case).
Thanks.
Click to expand...
Click to collapse
I was kind of just pulling at straws, and trying to answer two posts at the same time, sorry for the confusion. My habit, especially before unlocking the bootloader, is to push things to the sdcard then moving them and setting the right permissions and assingining the correct group and user.
As you've explained things, I don't know why it shouldn't work. Mine is a 4.1.2 OTA. It was originally rooted before upgrading and using Voodoo root keeper but between that and Supersu paid version I was able to reinsert root again after a factory reset, which was a stroke of luck as others lost it. I don't think it would matter which root method is used but I could be wrong; esentially its just allowing us to access the build.prop file to edit at all. I don't remember if I had modified the build.prop before or after the reset. I know that it was working both before and after I unlocked the bootloader though. As for the placement of the line, I put it at the end. I also, out of habit, hit enter for a new line for this type of thing. Afterwards, though, there is now new things that Pimp My Rom has inserted (Some of the tweaks in that package are old and I'd advise people to stick with close to stock as possible when using it unless they know what those lines mean; and there's some build.prop myths still floating around XDA that are not good ones, one of which I know Pimp My Rom uses and looks pretty apealing to select). So, now I have some stuff after it. If there were other things added to your build.prop, then perhaps moving the line to the end of where the default configuration ended... grabbing at straws again with this last sentance but in the lack of information I'm just trying to be helpful
Perhaps if people also with this problem, in addition to answering your question about the root method they used, also posted which carrier branding they had it might reveal something, or rule it out. <-Put that in bold for you
I am VZW with Nova Pro, and I get the systemUI FC as well. After much research, I haven't heard of too many people with PHONES that have been successful in this hack, so I tried it on my GTab 2, and same thing.
After spending entirely too much time looking into this, I purchased Full!Screen+, set the apps that I wanted full screen, and I'm set (oddly enough, this didn't work on my GTab, so I also purchased Hide Bar for that device. I prefer FullScreen+ because the truth is, there's only certain apps that I care about being full screen (Netflix, games, youtube...).
The biggest problem with FS+ is that it hides the notifications. Honestly, I don't really care about that either when I'm doing one of these other activities. After all, we have a notification light.

Categories

Resources