I have (or rather had :( ) a Glass running the XE8 version of software. It did not receive any automatic updates since it was rooted (as expected).
I tried to update it to XE12 using the system image from https://developers.google.com/glass/tools-downloads/system, and now it won't boot.
I can see the screen light up for a moment when it tries to boot, but the Glass logo does not come up. Instead, it just reboots itself over and over. Sometimes the screen flashes white instead of the usual reddish-gray.
I can still boot to bootloader using the hardware method. I have tried flashing XE11 but the result is the same.
I have a couple of questions that I think could be related to the problem:
1) There is a note on the system image download page regarding a "firmware change" in XE10 that prevents installation of earlier system versions (which includes XE8). Could that be my problem? Does that refer to low-level firmware change? How is that update applied when using the OTA update mechanism and can I apply it manually?
2) There is a relatively large userdata.img file in the system image .zip, however it does not get flashed using the fastboot update method:
fastboot -w update glass_1-img-947604.zip
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: 0.5
Baseband Version.....:
Serial Number........: [device serial]
--------------------------------------------
checking product...
OKAY [ 0.002s]
sending 'boot' (4528 KB)...
OKAY [ 0.208s]
writing 'boot'...
OKAY [ 1.670s]
sending 'recovery' (5334 KB)...
OKAY [ 0.243s]
writing 'recovery'...
OKAY [ 1.797s]
sending 'system' (485525 KB)...
OKAY [ 21.414s]
writing 'system'...
OKAY [ 64.458s]
erasing 'userdata'...
OKAY [145.384s]
formatting 'userdata' partition...
Erase successful, but not automatically formatting.
File system type not supported.
OKAY [ 0.002s]
erasing 'cache'...
OKAY [102.827s]
formatting 'cache' partition...
Erase successful, but not automatically formatting.
File system type not supported.
OKAY [ 0.002s]
rebooting...
If I try to flash userdata.img explicitly I get the following error:
fastboot flash userdata userdata.img
sending 'userdata' (137046 KB)...
OKAY [ 6.049s]
writing 'userdata'...
FAILED (remote: : Sparsed Write)
Is the userdata image supposed to be written to the device?
3) Is there any way of getting the boot log using fastboot to determine what causes the crash?
Thanks.
UDPATE: I have flashed the XE8 image back and now the Glass is stuck on the empty battery screen despite being plugged in for a couple of hours. However I have had charging issues with this unit before, hopefully it gets resolved overnight.
UPDATE #2: Having been left to charge overnight the device was displaying the empty battery icon with a question mark when I got back to it in the morning, however after forced reboot it seems to have booted up fine into the old XE8 system. My next step will be to restore it to unrooted state and attempt to update it using the OTA update mechanism.
I have managed to get the update working.
If you are still running a pre-XE10 system, chances are that straight reflashing of the system image to a post-XE10 version is not going to work. My best guess is that it has something to do with lower level firmware that cannot be updated simply through flashing the boot/system partition.
So if you have a rooted pre-XE10 Glass, the way to get it to update to XE12 or later is to restore it to unrooted state by flashing the boot.img from an unrooted system image.
If you have already flashed a post-XE10 version and the device won't boot, make it boot to the bootloader using the hardware method as described here: Having issues seeing GLASS in Fastboot
and flash the whole system image of a pre-XE10 version.
The links to old pre-X10 images are no longer available on the Glass developers page, however the files are still there and can be located with a bit of googling.
I am not sure that restoring the oem lock after flashing the unrooted boot partition image is required, but I did that just in case:
fastboot oem lock
Reboot the Glass afterwards and it should be able to auto-update to the latest XE version. The check for updates can be triggered by plugging the USB cable in.
When the update is complete, just repeat the original rooting steps if you need it rooted.
Related
I am trying to install Android 10 on an LG Nexus 5x (bullhead) smartphone. I installed the TWRP app, downloaded the Pixel Experience (the OS). I booted into TWRP recovery mode, and installed the OS, then rebooted.
After rebooting, the phone starts with the screen of language setup. Right there, the message "Google Services Framew...keeps stopping" keeps popping up, and I can't press on anything else.
I restarted the phone, went back to TWRP recovery mode, wiped data and installed the OS again. But that message still insists. Is there any way to fix it, or I've just broken the phone forever?
I finally found the offical forum for this Android 10 OS: https://forum.xda-developers.com/nexus-5x/development/pixelexperience-nexus-5x-t3861437/page141
Apparently, many people also experience this issue. I will look further for the solution on the official forum.
I finally found the answer. The Pixel Experience ROM must be installed in a decrypted data partition. Mine is encrypted, so I must remove the encryption.
The simple way is, instead of "Wipe", to choose "Format Data" in the TWRP recovery mode, then proceed as usual.
I've been fighting Nexus Root Toolkit for a while and decided I must be missing something obvious. I have a Nexus 7 2013 edition. I flashed it 6 mos ago and the result was a fully-rooted device that, when I opened an adb shell, the shell opened as root. I recently flashed it up to Marshmallow and I no longer have root when the shell opens. For the life of me, I cannot figure out how to get that back.
When I do adb root, I get a warning that adbd cannot run as root in production builds, so clearly I have a production build and need to change it, but I'm not sure how or to what.
I have figured this out - took a while to remember. NRT comes with a "modified boot.img" which can be used, according to the tool, to "temporarily boot a modified boot.img to enable running privileged commands". Last time around, I replaced the boot image with this temporary image.
I'd do that now, but the current modified boot image never fully boots. I get full device access via adb (including shell which defaults to root), but the OS won't fully load.
I will update this answer when a new boot image is released which actually works. Meanwhile, it'll be tedious but I'll just keep putting it into 'temp boot image" mode when I need this access.
My question is that is there any chance that any command in adb can damage (both hardware and software) my android phone (my phone is not rooted) and if software can it be recovered by factory reset? It is Micromax A120 and runs on android 4.4.2.
Yes, you can easily mess up your phone if you mess with ADB and don't know what you are doing. This is particularly true if you are using the 'Recovery' options (flashing new software to your device) in particular, if don't do this correctly, there are opportunities to mess things up (particularly if you are not patient, and don't wait for all operations to complete).
For the most part ADB is just a communication mechanism, and if you are careful to do only things you are confident are safe, there is minimal risk.
Bottom line, there is nothing specific about ADB that is risky, but it is a tool, and if mis-used could cause issues. Use it carefully, and you should be fine.
With adb you can delete and copy data on your mobile phone. So you can loose data or damage the Android System. However you have every time the chance to go into fastboot mode and flash a new Android ROM using the fastboot tools. You only can damage your Android device if you flash a corrupted bootloader using fastboot.
So in short form:
ADB: You can delete data but you have everytime the chance to recover your system. (However you can loose all your data!)
Fastboot: You can destroy your Android device if you flash a corrupted bootloader. It's irreparable.
I am developing an app and when I uninstall the phone kind of semi-reboots.
This is my old post:
I have a strange problem with my phone. I am using SAMSUNG GALAXY 5
(GT-I5500) with Android 2.2 on it (not rooted).
I am an android developer and I have been doing pretty advanced apps.
However, sometimes when I am testing and installing an application the
phone reboots.
I'm starting it trough Eclipse but I do not know what exactly what
causes the phone to reboot.
It is not heat for sure, as I keep my phone cool enough.
It is not from the app source itself as the phone doesn't reboot while I am using the application but on installing time
It is not storage I think, because I have 26 MB internal and 1GB external memory free and the app is no more than 2 MB.
So my question is what could cause the phone to reboot?
In this context I define "reboot" as the phone showing the initial SAMSUNG screen, like normal booting but without the prompt for PIN. This is why I conclude it is something like semi-reboot or I do not exactly know.
Having experienced the same problem, I found that deleting dalvik cache and formatting cache partition helped - I can't tell which one of those two did the trick, but I can now happily uninstall apps again, without the device spontaneously rebooting.
Both operations I was able to perform in recovery mode, using ClockWorkMod rescue system, and they are non-destructive. No actual data or apps are lost, only next reboot takes longer, due to dalvik cache being rebuilt.
Today, close to a month later, that problem showed again, so I was able to test which of those two action fixes it. Turns out it was erasing the cache. Dalvik cache was left alone, deletion was possible afterwars nevertheless.
I have this exact problem with my LG G4. Whenever I try to uninstall an app the phone will just reboot. Luckily there is a way to remove unwanted apps if your phone has an expandable memory option through micro SD. Just transfer the unwanted app on the SD card then remove the card. The app will no longer exist on your phone. You can then just delete the app from your SD card using a PC. This doesn't help resolve the actual OS issue on your device but at least it's a quick fix for anyone who's looking to free up some space. Hope it helps!
Spontaneous reboots under unclear conditions, one of the "fun" things you get for free with Android. Not on each and every device, OS version or combination thereof, but quite too often.
With the following instructions you will loose all your data on your phone.
Try this: Get into the recovery mode (adb reboot recovery or start the phone with pressing (and holding) volume down, then press and hold the center key, then power on), then wipe data/factory reset, wipe cache partition.
(I experienced similar reboots but not with an I5500, so I don't know if this will help in this situation. It helped with a Motorola Milestone/Droid after upgrading to Android 2.2.)
I was able to fix this problem by wiping the davilk-cache thanks to Deleted User's experience. However, wiping the cache partition was not necessary in my case. I'm rooted stock Android 4.4.2 KitKat on a Galaxy Tab 3 SM-T210R.
the camera of my mobile (running Eclair-update1) keeps being non-responsive in 90% of the time, so I assumed a hardware defect at first. After whiping the cache and the phone user data sereval times it worked again. At least for a while. Now it stopped working again.
Browsing the net I found quite some users who experience the same problem and had a hard time after whiping their user data off the device.
So my question would be: how close can I get to the hardware with the SDK? I'd like to write an app to influence hardware states (e.g. re-initializing the camera, remounting the SDcard aso.), but I'd prefer doing it - if possible - with the SDK instead of NDK.
Thanks in advance!S.
It's not a question of sdk vs. ndk, but of underlying operating system level permissions preventing ordinary (aftermarket vs. manufacturer/carrier installed) android applications in general from doing raw hardware access.
Download Android SDK to your computer
Boot device to recovery
Connect USB cable to PC
Run adb shell then
umount /data
umount /system
e2fsck -fv /dev/block/stl9
e2fsck -fv /dev/block/stl10
Taken from forum.xda-developers.com/showthread.php?t=1396366