titokhan / boot-unlocker-gnex Goto Github PK

External commands should not be run from main thread.  Investigate the use of 
background threads to exec() su for changes, and Handlers to sync up and update 
the GUI.

This should ideally to the su's that _read_ param as well as those that write 
it.

What steps will reproduce the problem?
1. Launch the app
2. Accept the SU request with "always allow"
3. Click "Lock" or "Unlock"

What is the expected output? What do you see instead?
Some users are experiencing a SECOND prompt for SU access at this point.  Since 
root was already granted with "always allow", this should not be happening.


What version of the product are you using? On what operating system?
Need to find out what SU app(s) are being used by the users who experience the 
problem.


Please provide any additional information below.

My current way of calling su using exec() on the main thread is clunky.  
Investigate whether RootTools would be appropriate.

Users who keep their bootloader locked, usually keep stock recovery as well, 
for security.

One of the reasons to unlock the bootloader is to "fastboot flash" (or 
"fastboot boot") a custom recovery to make nandroid backups.  Therefore users 
may save time by flashing the custom recovery here.  This will avoid not only 
the need for fastboot (and a USB connection) but the need to unlock (for this 
purpose) as well.

We can flash the recovery .img file by writing directly to the recovery mmc 
partition.  We need a way (perhaps hash-checking) to verify that the recovery 
is intact, as well as a way to verify that it is indeed a recovery image, and 
for this kind of device.

We should give the user a choice of a "temporary" or "permanent" flash of the 
new recovery...

Devices that have received OTAs will restore stock recovery the next time 
Android starts up; devices which have never received OTAs do not, and will keep 
the flashed recovery until stock is manually reflashed.  The OTA installs 
bootloader-specific files /system/etc/install-recovery.sh and 
/system/recovery-from-boot.p.  If the user has these files we should give them 
the choice of moving them to a backup location or leaving them alone; this is 
the "permanent" or "temporary" decision.

For devices that do NOT have these files, we should figure out how to give the 
user an easy way to restore stock recovery.  Perhaps we can dump their current 
recovery to SD card.

I would like to support additional Nexus devices that have "fastboot oem 
unlock"-able bootloaders.  Supporting a device will require experimentation on 
the device, including locking and unlocking the bootloader, and dumping images 
of all the device's partitions, in order to learn where the bootloader stores 
lockstate.

Right now, the devices I would most like to add are:
Sprint Galaxy Nexus (toroplus)
Nexus 7 (grouper)

If you have one of these, or another Nexus device, that you are willing to hack 
on and risk wiping userdata, please let me know.

Users whose phones are in "Tablet Mode" using a custom ROM such as Paranoid 
Android may be unable to download from the Play Store. Switching back to Phone 
Mode should resolve the issue.

Can you please make the same app. for zenfone 6 also.. please.... :(
(from [email protected])

Since our target audience is knowledgable Android users, and we are doing 
low-level stuff to users' devices, they have the right to expect that we will 
log successes (at least for write operations) and failures to logcat for their 
perusal.

What additional functionality would you like to see?
-
Would it be possible to add support for the New Nexus 7 (2013 version)?

Is this an entirely new component, or an enhancement of an existing
component?  In the latter case, case please specify the component.
Enhancement

Please provide any additional information below.
-

What steps will reproduce the problem?
1. Launch app
2. Lock or unlock the bootloader using the appropriate button

What is the expected output? What do you see instead?
Bootloader Status should show the new state, as appropriate.  Usually it does, 
but sometimes it does not.  Changing the orientation of the app, switching apps 
then returning, or anything else that causes a UI update fixes the problem.


Please use labels and text to provide additional information.
This appears to be a race condition where the UI update occurs before the 
bootloader change has committed.

Would like to build a Tasker plugin, so that Tasker can lock/unlock the 
bootloader depending on whether you are in a "secure" location.

Of course users should have to _opt in_ to this (in Settings), so that access 
is not granted by default.

What steps will reproduce the problem?
1. Uninstall app.
2. Reinstall app.
3. Run app.

What is the expected output? What do you see instead?
Should see _one_ prompt from Superuser or SuperSU for root access.  Program 
should wait gracefully for access to be granted.  Instead sometimes remains 
blank and must be clicked before access request dialog appears.  App may 
timeout requesting access, or request access more that once during startup.

Quitting the app, launching Superuser or SuperSU and granting access to 
BootUnlocker in settings fixes the problem: it will launch correctly the next 
time.


Please use labels and text to provide additional information.
This may be a result of exec()ing su on the main thread to check bootloader 
status.

Before scribbling the param partition, we must check that this is indeed a 
Galaxy Nexus device.

405. That’s

Hi,
could you add support for the Oneplus One?

The bit for unlocked bootloader is at 0x000FFE10 in the aboot partition as you 
can see in my screenshot.
The tamper flag should be at 0x000FFE14

http://forum.xda-developers.com/showpost.php?p=54060141&postcount=395

Can we have Android notify us if somebody else changes the param partition, so 
we can update our UI?  This would eliminate the need to call su to read the 
param partition everytime we come to the foreground.

Add another line below Bootloader Status to hold extra info

Not sure about i18n issues in the displayed text.

Design promotional graphics for the Play Store:

* Promotional Graphic
* Feature Graphic

We should check for busybox before running.

What steps will reproduce the problem?
1. Start with unlocked bootloader PRIMELCxx bootloader
2. Use BootUnlocker to lock the bootloader
3. Confirm that BootUnlocker shows "locked"
4. Reboot to bootloader

What is the expected output? What do you see instead?
Bootloader screen should show "LOCKED".  Instead is remained "UNLOCKED".


Please use labels and text to provide additional information.
Need to test the other way (locked -> unlocked); but this is dangerous if the 
app no longer works.
Also need to verify which bootloader versions experience this problem.  So far, 
issues reported in PRIMELC02 and PRIMELC03.

Make the locked / unlocked / unknown text different colors?

Display an image for the lock status?  Image button?

Need to create at lest the following before making the app available on XDA and 
the play store:

* Application Icon
* Short Description
* Long Description / What this is for and why you should use it
* Very Long Description / Exactly how this work, and where to view the source 
code
* Screenshots
* High Res application Icon
* Promotional Graphic
* Feature Graphic
* Promo Text

Having an initial draft of these is high priority.  Having improved version 
(especially graphics) will be separate Priority-Low issues once this issue is 
closed.

Although the application does not store any user data remotely (or even 
locally, at the moment), it is worth having a privacy policy which discusses 
the root in general.

Since the next step after unlocking the bootloader is usually to reboot into 
the bootloader, provide a reboot option, with the usual choices:

* System
* Bootloader
* Recovery
* Shutdown

Make calls to "su" to do this, after cleaning up.

Device data needed

What steps will reproduce the problem?
1. Have a previously rooted Galaxy Nexus 4.1 upgraded to 4.2. Restore root if 
necessary after upgrading.
2. Run BootUnlocker


What is the expected output? What do you see instead?
Expected Output: Root Access should be granted, and should be able to get 
status, and lock or unlock the device
Actual   Output: Status says it could not get root access. Other root apps can 
get root access without problems


What version of the product are you using? On what operating system?
BootUnlocker 1.1
Stock Android 4.2
SuperUser 3.1.1



Please provide any additional information below.

Design new application icon, both for the launcher and the Play Store.

Investigate the user of <has-library> tags to further limit the filtered 
devices to G-Nex.

Google Code:
* Project Description
* Links
* How it works / Thanks

XDA:
* Promotional Description
* Links
* How it works / Thanks

Play Store:
* Promotional Description
* Links
* Promo Text

please support Moto X 1Gen
My Device Model Moto X XT1052

Submitted by: [email protected]

Some users have requested the ability for the app to remove itself from the app 
tray, and instead be available by a "secret code" form the dialer.

Will investigate how to do this: probably involves accepting a particular kinds 
of Broadcast Intent.

Do we really need busybox, or can we do this with stock dd or a Java program?

Current setup (if I'm right) may end up in undesired situation if one uses a 
secure setup (I mean setup no one can abuse by rebooting to unprotected 
fastboot/recovery):
* phone is rooted (and BootUnlocker is installed)
* bootloader is locked
* stock recovery
* OTA update is proposed and accepted
=> oops!
* phone is not rooted anymore
* bootloader is locked
* stock recovery
=>
At that point one will have to use again fastboot oem unlock and erase 
everything

So what I'm doing on my phone:
 echo "# Remove me to allow OTA update" >> /system/build.prop

This makes sure nobody can apply OTA by accident before unlocking bootloader 
(to allow booting on alt recovery and applying rooting again)

This could be actually a feature of BootUnlocker:

Prevent automatically that OTA updates can be applied (and root access lost) if 
bootlocker is locked.

Some details of the full procedure: 
http://wiki.yobi.be/wiki/Android#Rooting_and_OTA

I know rooting software try to preserve root access over OTA but by experience 
over those last OTA, it often fails so it's critical to have an unlocked 
bootloader when applying OTA update.

Make a lock/unlock widget for the homescreen?

Por favor hagan una para el motorola moto g  un saludo
(from [email protected])

POR FAVOR HAGAN UNA PARA EL MOTOROLA MOTO G
(from [email protected])

http://forum.xda-developers.com/showpost.php?p=58014105&postcount=447