First, I know this question doesn't exactly belong here, but I'll explain later why I'm asking here instead of on the specific android board.
I'm developing an app, and yesterday I had some problems with sqlite, so I went on to checking how my database looked like. Found out I didn't have the sqlite3 actually installed on my phone, so I followed this answer to install it. I got some problems with the pushing part so I tried to alter the permissions on /system to try and make it work. I basically ran "chmod 7777 /system" on an adb shell. After that I still couldn't push the sqlite to the phone, so I quit the shell and tried to open it again, but I got a no permission error. When I unlocked the phone, every possible app (including system ones) started crashing, one after the other. I freaked out and took the battery off. at that time I had the phone connected through usb to a Ubuntu pc, with no headphones connected. When I turned the phone on again everything seemed to work properly, and I managed to push the sqlite to the system folder without any problem. I thought the problem was over and moved on with debugging and developing.
When I was going home, I was listening to some music with headphones and a friend called me. I answered but couldn't hear anything. I then later discovered that since then I can't hear anything and no one can hear me too. Every other sound related function works fine, except calling. I'm not hearing even that calling beep.
So that's why I'm asking here, as it's actually a question related to developing and coding stuff. Please, if anyone knows what this might be, answer here, I have tried many things to get it working again, but none of them worked. I read it could be a headphone related issue, but that seems to occur only on some motorola phones or something. I have a Galaxy S advance, 3 or 4 months old. I have also tried to change the chmod setting again, to chmod 4755 /system, but it remains the same. I'm getting really desperate here, I don't think customer support can solve this.
As nobody ansered yet, and also I think this is a too specific error for many people to know, I'll report what I did and discovered:
I changed the permissions of all the files in the folders /system and /system/app, not recursively.
A friend later told me UNIX systems sometimes have problem with executing programs that have too many permissions
All the system applications had full 777 permissions.
So I rebooted the device many times, even made a factory reset on it, but nothing seemed to work. So I began changing the permissions again. I tried to change everything to the default permissions (I used a friend device of same model as reference), and when I changed the system/app folder permissions to 755 and rebooted, it worked again!
So for all of you who don't know exactly how chmod and permissions on UNIX works, think twice before start to mess up with it.
Related
This is hands-down the most esoteric question I've ever posed on this site, but here goes:
Following the instructions on Cyanogen Mod's site I was able to make it as far as flashing the linked recovery image.
However, now that I've done that, Ubuntu no longer recognizes or mounts the device, so I can't proceed to the next step.
I'm at a loss as to what to do at this point, so any advice would be appreciated.
Add your device's vendorId to home/.android/adb_usb.ini file and then restart the adb server. If that doesn't works, please reboot your system and connect your device to a different port and check. Hope it solves your problem.
This has nothing to do with eclipse. Every other question about logcat not displaying anything on this site is about eclipse, so far as I have found. This is not one of them.
I have an LG G3. It's rooted and bumped. It's pestering me ALL THE DAMN TIME to update (there's apparently no way to shut this off with the Verizon model). I really, really, REALLY want to use a custom ROM to end this pain. Thing turns on the screen and leaves it that way until I notice and tell it to bug me sometime within the next 24 hours.
I set it up with Skydragon, which from what I can tell is the stock ROM de-bloated and slightly modified to run faster and more efficiently.
Apparently though it has no log. I can connect to it with adb just fine. I can upload apps and run them. What I can't do is see anything at all in logcat. I even tried opening the main log device on the phone, it was empty.
My best guess is that either the kernel doesn't have logging facilities in it, which would seem stupid so I doubt it, or the logging service isn't turned on (assuming there is one). I don't see any log service file in the init.d directory (skydragon I believe uses init.d).
Anyone know what I need to do here to get logging working? I'd sort of like to stick as close to stock as possible at least for the time being. It's getting frustrating though. Either I'm constantly arguing with the system upgrader, or can't debug my apps with logs. Neither is what I'd call acceptable.
I did try asking this same question in the skydragon thread at xda but got no reply. It's been a week so I don't expect one.
Was able to get this going by selecting the stock kernel in the aurora install. With this done the expected logcat content is there. There may be a better answer, but it's yet to be provided. I'll leave this open just in case, but this be here for those searching for WTF might be going wrong needing to fix it.
I am trying to change the value stored in /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq which is currently set to "1512000". I am attempting to do this via adb shell.
I type su and then navigate to /sys/devices/system/cpu/cpu0/cpufreq. I then type
chmod 777 scaling_max_freq
I confirm that the chmod worked by typing
ls -l scaling_max_freq
and sure enough it is listed as -rwxrwxrwx. I then type
echo 124200 > scaling_max_freq
and then
cat scaling_max_freq
sadly this reports that the file is unchanged as "1512000". None of the lines executed responded with any kind of error.
Maybe the governor is immediately overwriting this? Maybe I need some extra type of permission? Maybe this is somehow fundamentally not allowed on an android device and I need to control the clock speeds via a different mechanism altogether? The problem must be soluable somehow as it it performed by SetCPU.
BTW, this was all on a rooted Sony xperia z, Android 4.4.2, build number 10.5.A.0.230
Someone suggested attempting to write to scaling_min_freq... I tried it and to my surprise it worked. I was even more surprised when, afterwards I set scaling_max_freq and that worked too. I found this amazing because this document suggests that if anything you should set them in the reverse order.
Anyway, it all seems to be working now.
while i add this line to my code
Process process = Runtime.getRuntime().exec("su -c");
or
Process process = Runtime.getRuntime().exec("su");
trying to run the"su" command,
process.exitValue() returns 1 which means fail.
This happens to my one Android device while my the other rooted android device works perfectly with this command. (process.exitValue() returns 0)
Can anyone teach me how to trace the error or how to fix it?
I am confused with this error while my two devices almost in the same condition.
Thanks for your reply in advance.
Hi guys,
Thanks for discussing this issue with me. Your reply hints me a clue that I have removed my old su and place a new su. Luckily enough, the return value is now 0 and I guess it means correct. However, Does any of you might know what is the difference between .exec("su -c") and .exec("su")? Please let me know if you know the difference.
I suspect you lack Superuser on the problematic phone, do you?
Or at least something about Superuser could be wrong (versions, binaries...)
su calls Superuser which allows root access or not.
Many problems seems to occurs on latest versions of Superuser.
Try to remove it and install other version:
http://goo.im/superuser
Another note: if you're trying to gain root access or to execute commands as root, you should not only use exec("su"). Take a look at the RootTools a library by stericson himself ;)
http://code.google.com/p/roottools/
The command su (which means Super User) is only valid on rooted phones. That is why your rooted phone recognizes it and works as expected. So, either you root your other device(s) or drop this idea on non-rooted phones :)
Since this is the only result I got for searching for the phrase, thought I'd post an update for anyone else coming across this.
Was following the instructions for installing Cyanogenmod. My issue was resolved by disabling Mass Storage mode on the device (change it to one of the other options).
I'm debugging an Android app on an HTC tablet and every time I uninstall the app, the device reboots. Uninstallation also happens as part of trying a new build, so any changes to the app require a reboot before testing. This is predictably aggravating for development.
The problem sounds similar to that described here except that there's no mystery about it in my case. Uninstall => reboot. Change app and debug through Eclipse & adb => reboot. Wiping all the data on the device as suggested in the only answer to the similar problem is not desirable, especially as there's not much indication that even that poster saw it as anything other than the tech equivalent of sacrificing a chicken.
Can anyone tell me why this is happening and how to prevent it?
I'm not offering this as an answer (at least not yet) but need more space than a comment provides to brainstorm about how to investigate this
I'd be tempted to take a safe "hello world" type app and merge it into the project as its own activity. Then comment out all the real functionality from the manifest and java files. That should leave only the hello world and the resources. See if the device survives uninstalling that after a run - if not, guess you might have to suspect the resources.
This should do the commenting - or you could just remove files wholesale from the tree
find . -name "*.java" | xargs -I f sed -i 's/^/\/\//' f
(Some editors will do block comment/uncomment, emacs will do arbitrary operations on a column of a file.)
Then I'd either uncomment the skeleton of the real activity - ie, all the onCreate, onStart, etc methods with no operations in them, and restore that activity to the manifest. Or else I'd restore functional java code, but leave the activity out of the manifest. You could then incrementally add more and more functionality until you get a crash.
If you have any ndk libs or even java libs you could play a similar game with those.
You can also try to run logcat during the uninstall and see if any messages make it out before the device hangs up on you.
Oh - and a major question, is this a kernel reboot, or an android runtime restart? In the later case, adb & logcat should probably survive, and /proc/uptime will not be reset to a small number.
If you get it down to a suspect operation, it would be great if you could post a description of that - I have a similar device in my test collection and would be curious to see if it has the same apparent bug. Also HTC has a number of "Developer Evangelists" who might be a point of contact.