Database Develop

[Q] Naming the nook device / hostname?

Does anybody know how to change the name of the Nook Color? In order to use an application in Citrix, it needs to have a specific name, and I can't figure out how to change it.
I've seen various ideas, such as:
http://forum.xda-developers.com/showthread.php?t=668300
which says to change the /proc/sys/kernel/hostname
I've done so, but disconnecting and reconnecting the wifi with the desired name for the NC in the above file does not work; the name stays the same. For me, the name is ROID7047BCFB-EB96-44.
How does the android/linux OS figure out a name for the NC, and how can I change it?
Thanks in advance for any help.
Update:
pinging ROID7047BCFB-EB96-44 works, as does pinging NEWHOSTNAME (what I want my NC to be called), both give the same IP address. However, my Citrix receiver still recognizes me as ROID* and boots me off.
Maybe this is some kind of DNS issue, or how do I get rid of the ROID* name and get my device to be recognized only by NEWHOSTNAME?
I suppose I can ask the Citrix/I.T. administrators to give me access on my NC (which they probably won't support doing), or I can rename my NC to something that already has access in Citrix.
It really shouldn't be that hard to name your NC, as you can any computing device.
Do I have to go into userinit.sh to set localhost to NEWHOSTNAME, or edit the init.rc file, or edit the .IMG on the ROM (it's been a while since I played around with unix, and so I'm pretty new to this stuff)?

Nook Color Device ID / Hostname
Didn't want to start a new thread on this topic...
Our network admin sees unknown devices as a security threat (or annoyance) to his network. He therefore requires a unique hostname to obtain a DHCP lease.
A hostname of "localhost" (the NC default), is seen as blank by the server. The Nook Color (and many other Android devices) must be rooted and modified to gain access.
Several posts recommend changing net.hostname. This did not work for me. Changing /proc/sys/kernel/hostname, however, would work.
For a single instance, use the following from a root prompt. THEN TURN OFF AND TURN ON WIFI to request a new DHCP lease.
# echo NEWHOSTNAME > /proc/sys/kernel/hostname
EDIT: Removed paragraph about setting at boot until I figure it out.

To set HOSTNAME / Device ID at boot
Thanks to JoshMiers for instructions on persistent settings following a reboot...
http://forum.xda-developers.com/showthread.php?t=901791
To set the HOSTNAME at boot (on rooted stock eclair, anyway)...
1. Create (via adb or RootExplorer) file /data/boot_complete_hook.sh
2. Add the following lines via a text editor (on Windows use Notepad++):
Code:
#!/system/bin/sh
#
## Set hostname/deviceID
#
echo yourchosenhostname > /proc/sys/kernel/hostname
3. At root prompt, change properties of new file
Code:
#chmod 755 /data/boot_complete_hook.sh
At root prompt, test to see if it works by executing
Code:
#/data/boot_complete_hook.sh
#cat /proc/sys/kernel/hostname
I did not need to reset the wireless after booting. If necessary, code could be added to the file to renew the DHCP lease or reset the wireless (tiwlan0).
I did have difficulty using ADB to do this, as Josh describes, and did not take time to debug. Instead, I used RootExplorer and Terminal to do it all directly on the NC.

KBMN said:
Does anybody know how to change the name of the Nook Color? In order to use an application in Citrix, it needs to have a specific name, and I can't figure out how to change it.
how about this?
http://forum.xda-developers.com/showthread.php?p=17287446#post17287446
Click to expand...
Click to collapse

Well, I can use the setprop net.hostname command to set the device hostname. However, the Citrix application takes the "clientname" from the android_id field in /data/data/com.android.providers.settings/databases/settings.db, regardless of the hostname. So, the Citrix application sees the device as "ROID"+android_id. I can't figure out how to get rid of the "ROID" part so I can make the device "clientname" to show as whatever is desired (after changing the android_id). Tried to put in a backspace character in the field, as "\b" to get rid of the "ROID" part, but that didn't work. Oh well.

[DEV GUIDE][2016.12.22] How-To SU

Guidelines for problem-free su usage
How-To SU is my guide on using "su" in your own programs (to execute commands as root). The guide covers the major common pitfalls and also provides example code, as I have been asked by several developers to provide.
I also did a presentation on this stuff at the Big Android BBQ 2012, so if you're looking for the article and code promised there, here it is!
The text is too long to copy here, but you can find it here:
http://su.chainfire.eu/
Example code is located on GitHub:
https://github.com/Chainfire/libsuperuser
If you are not an app developer, you have no business posting in this thread. This thread is for developer discussion on the article/example code only. In fact, I do not expect many posts in this thread at all - it's all rather straightforward, and this is not a helpdesk.
Moderators: Do not move this thread to a development subsection, 0-posters need to be able to reply to it.

Awesome job man, I definitely learned some new stuff. I've done a little bit differently than your implementation: instead of doing AsyncTask -> run su code inside I did this in my Root class:
Code:
class BackgroundThread extends AsyncTask<String, Void, Void> {
private String s;
public BackgroundThread(String command) {
s = command;
}
@Override
protected Void doInBackground(String... command) {
Process process = null;
DataOutputStream os = null;
try {
process = Runtime.getRuntime().exec("su");
os = new DataOutputStream(process.getOutputStream());
os.writeBytes(s+"\n");
os.writeBytes("exit\n");
os.flush();
process.waitFor();
} catch (Exception e) {
}
finally {
try {
if (os != null)
os.close();
else
process.destroy();
} catch (Exception e) {
}
}
return null;
}
}
And then receive the command in the parameter:
Code:
public void run(String command) {
new BackgroundThread(command).doInBackground();
}
Is this acceptable from your point of view?

No it isn't acceptable, but the reason is not what you might think.
Using a generic AsyncTask derived class to run su calls can be a solution. As long as your code ends up running in the background, all is good. However, in my experience what usually happens is that you have to do a lot of things in the background.
For example, imagine that during your app's startup, you need to check some files, perform some su calls, check some more files, do some computations, etc. Those should all go in a single AsyncTask's doInBackground method. That way you can use onPreExecute and onPostExecute to show and dismiss a dialog that tells the user you are busy.
Furthermore, if you had 10 su commands to run, would you just call new BackgroundThread ... 10 times? As the call should return before the su command is finished executing, the order of the executions of those commands becomes semi-random, you can't depend on them being run in any specific order, it even differs between Android versions (some versions run AsyncTasks serially, others run X of them in parallel). Not to mention that you shouldn't create 10 separate su processes to run 10 commands unless you have a good reason. Batching commands together == much higher performance.
The above does depend on which commands you need to execute, the needs of your application, and how you use it. If you only have to execute a single su command, it can be done that way, but I think in general this is not an ideal solution.
Now, the reason why your solution is truly unacceptable is because you are calling doInBackground. This does not make the code run in the background. You override doInBackground and insert your code, but you call the execute method. You should call your code like this:
Code:
new BackgroundThread(command).execute();
Else you're still calling on the main thread !
If you really want to keep using this method, keep in mind that you can actually pass parameters to the execute() function that in turn will be passed to doInBackground. Look in the AsyncTask documentation ...

that's a nice read
thanks for the guide

Chainfire said:
No it isn't acceptable, but the reason is not what you might think.
Using a generic AsyncTask derived class to run su calls can be a solution. As long as your code ends up running in the background, all is good. However, in my experience what usually happens is that you have to do a lot of things in the background.
For example, imagine that during your app's startup, you need to check some files, perform some su calls, check some more files, do some computations, etc. Those should all go in a single AsyncTask's doInBackground method. That way you can use onPreExecute and onPostExecute to show and dismiss a dialog that tells the user you are busy.
Furthermore, if you had 10 su commands to run, would you just call new BackgroundThread ... 10 times? As the call should return before the su command is finished executing, the order of the executions of those commands becomes semi-random, you can't depend on them being run in any specific order, it even differs between Android versions (some versions run AsyncTasks serially, others run X of them in parallel). Not to mention that you shouldn't create 10 separate su processes to run 10 commands unless you have a good reason. Batching commands together == much higher performance.
The above does depend on which commands you need to execute, the needs of your application, and how you use it. If you only have to execute a single su command, it can be done that way, but I think in general this is not an ideal solution.
Now, the reason why your solution is truly unacceptable is because you are calling doInBackground. This does not make the code run in the background. You override doInBackground and insert your code, but you call the execute method. You should call your code like this:
Code:
new BackgroundThread(command).execute();
Else you're still calling on the main thread !
If you really want to keep using this method, keep in mind that you can actually pass parameters to the execute() function that in turn will be passed to doInBackground. Look in the AsyncTask documentation ...
Click to expand...
Click to collapse
Hmm... I thought calling new BackgroundThread(command).doInBackground(); was doing it in the background thread... if I call new BackgroundThread(command).execute; the commands won't be called at all until I close the application/activity.
I don't do X new calls, for example in the BootService I just batch commands together and execute it once.
I'll use your code and see how it works.

Very nice reading. I always use AsyncTask for su commands, although I learned it the hard way
I remember few months back I couldn't figure out why supersu pops up when timeout is at 2-3 seconds
Sent from my HTC EVO 3D X515m using Tapatalk 2

I generally work with desktop apps. Is there a reason to not use Runnable?
Code:
public void liveBackgroundShellCommand() {
Runnable r = new Runnable() {
public void run() {
boolean LinkLaunched = false;
try {
String[] params = (String[]) Statics.LiveSendCommand.toArray(new String[0]);
Process process = new ProcessBuilder(params).start();
BufferedReader STDOUT = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader STDERR = new BufferedReader(new InputStreamReader(process.getErrorStream()));
This is how I set up a background shell. Then I just pass in the su -c command. Is there a disadvantage to this?

AdamOutler said:
I generally work with desktop apps. Is there a reason to not use Runnable?
Code:
public void liveBackgroundShellCommand() {
Runnable r = new Runnable() {
public void run() {
boolean LinkLaunched = false;
try {
String[] params = (String[]) Statics.LiveSendCommand.toArray(new String[0]);
Process process = new ProcessBuilder(params).start();
BufferedReader STDOUT = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader STDERR = new BufferedReader(new InputStreamReader(process.getErrorStream()));
This is how I set up a background shell. Then I just pass in the su -c command. Is there a disadvantage to this?
Click to expand...
Click to collapse
If this is about desktop Java, then I don't know. I don't use desktop Java, but in most languages and frameworks it is generally frowning upon to block the UI thread, and the UI thread is usually the main/default/first thread.
If we're talking about Android, then this may be bad, depending on what you are doing. A Runnable by itself says nothing about threading or being in the background, a Runnable is just a generic way to define some code you want to run somewhere, sometime.
The code you pasted here does start the process, but it does not wait for the process to exit or read/write to the streams. As such, this piece of code does not block, and is fine. 9 out of 10 times however, a piece of code like this is going to be followed by something like process.waitFor() or reading from STDOUT/STDERR in which cases it does block, and is thus holding up your UI thread and thus bad.
Furthermore, as detailed in the article, calling "su -c" can be errorprone.

Right. I generally launch in a Thread T=new Thread(..). I'be never used AsyncTask. I'm just wondering what its all about.

AdamOutler said:
Right. I generally launch in a Thread T=new Thread(..). I'be never used AsyncTask. I'm just wondering what its all about.
Click to expand...
Click to collapse
Ok, yeah that's fine. AsyncTask is pretty much a Thread wrapper with handy utility functions (onPreExecute, onPostExecute, onProgressUpdate) that is specifically aimed at running a short-lived task away from the UI thread, often with UI feedback (it's brilliant for use with progress dialogs, for example).

Chainfire said:
Ok, yeah that's fine. AsyncTask is pretty much a Thread wrapper with handy utility functions (onPreExecute, onPostExecute, onProgressUpdate) that is specifically aimed at running a short-lived task away from the UI thread, often with UI feedback (it's brilliant for use with progress dialogs, for example).
Click to expand...
Click to collapse
Ah ha! its like a SwingWorker() but with better functionality... Thanks Chainfire! I just looked and apparently it's not available on desktop or I would be switching immediately. That's a wonderful class.

Chainfire said:
Guidelines for problem-free su usage
How-To SU is my guide on using "su" in your own programs (to execute commands as root). The guide covers the major common pitfalls and also provides example code, as I have been asked by several developers to provide.
Click to expand...
Click to collapse
Great & sorely needed topic, thank you. I rarely check this forum, but stumbled in here. Hopefully busy devs of SU apps will be pointed here by someone.
I continue to have lots of problems with SuperUser/SuperSU apps that seem to be pre-configured or something to prevent SU access; and the user is never even prompted. But I don't think this is being discussed here.
At some point in the early development of ICS ROMs I noted that SU calls were taking much longer, perhaps about 0.1 seconds. So I optimized the 4-5 seconds and 40 or 50 calls (including blind chmod's for files that didn't exist on many devices) to about 2-4 calls for most devices.
I know I continue to be guilty of calling SU, and shell, and various other things from improper places, such as UI threads, onCreate etc. But I don't think these cause too much trouble in general, so putting these in threads or wherever is an exercise I save for an app re-design.
My app currently allows selection of "SU Type", but it doesn't seem to be needed anymore, now that I'm avoiding the quoting problems I've had previously.
I use the system() call from C/JNI in a lib. My best/default is like this, where CMD is the command, and noting that \" is " escaped in C:
system ("echo \"CMD\" | su -c sh");
This works, but writes to the filesystem every time:
system ("su -c \"sh /data/local/cmd\""); // Write CMD to cmd file first.
The simplest, but I was having more problems with this for whatever reason; perhaps quoting issues:
system ("su -c \"CMD\"");

thx
---------- Post added at 11:03 PM ---------- Previous post was at 10:58 PM ----------
it is great

pisy3 said:
thx
---------- Post added at 11:03 PM ---------- Previous post was at 10:58 PM ----------
it is great
Click to expand...
Click to collapse
I'm trying to convert my app to use your example classes for running root commands, as most of my app was implemented ok, but I needed to change a couple of bits based on your document. Once chaning I keep running into the following error:
11-20 22:16:39.770: I/System(31924): libcore.io.ErrnoException: kill failed: ESRCH (No such process)
11-20 22:16:39.770: I/System(31924): at libcore.io.Posix.kill(Native Method)
11-20 22:16:39.770: I/System(31924): at libcore.io.ForwardingOs.kill(ForwardingOs.java:77)
11-20 22:16:39.770: I/System(31924): at java.lang.ProcessManager$ProcessImpl.destroy(ProcessManager.java:257)
11-20 22:16:39.770: I/System(31924): at eu.chainfire.libsuperuser.Shell.run(Shell.java:100)
11-20 22:16:39.770: I/System(31924): at eu.chainfire.libsuperuser.Shell$SH.run(Shell.java:149)
11-20 22:16:39.770: I/System(31924): at com.rageconsulting.android.lightflow.util.RootUtil.runRootUnixCommand(RootUtil.java:49)
I'm calling my own helper method which is just a wrapper around your Shell class and it's getting called from an IntentService so I'm not quite sure why this happens.

You can ignore that.
By calling exit here, the process is usually gone.
When it tries to destroy the process in this line, the process is already gone, so it throws that error message as there is nothing to kill/destroy.
Before Android 4.0 this message was not even printed into the log.

Update the library code with some changes (like proper gobbling). See GitHub

Hello dear developers of the supersu. first thanks for good work. I don't know if anyone informed but after htc one s jb update there seem to be some compatibility problems.

The article has been updated to v1.20.
Changes are clearly marked in the "Table of Contents"
http://su.chainfire.eu/

Does the library support other superuser apps too?

mcnamaragio said:
Does the library support other superuser apps too?
Click to expand...
Click to collapse
Yes, it's all about best practises when calling the su binary - it should work with all superuser apps.

Put Settings from hook

Hook is in PhoneWindowManager class, I need to put a value to Settings.System. ContentResolver from the available mContext variable is used.
I get the following:
Code:
InvocationTargetError: java.lang.SecurityException: Package android does not belong to 10036
10036 is UID of my module.

- Which context did you use to get content resolver?
- Depends on where your hook is.
Although your hook is in phone window manager, it still depends from where method you are hooking was called from. If it was called from different package that has different permissions (such as your module app), you will have to clear an identity of calling package while using system settings.
Something like:
Code:
long ident = Binder.clearCallingIdentity();
try {
// store to system settings or whatever
} finally {
Binder.restoreCallingIdentity(ident);
}
- Another option is to add necessary permission to your module's manifest

My module already has WRITE_SETTINGS permission. I use mContext variable that is available in PhoneWindowManager, never had a problem with it. Calling from a separate thread that is created in screenTurnedOff() method.
PhoneWindowManager has a lot of similar code involving Settings.System:
Code:
android.provider.Settings.System.putIntForUser(mContext.getContentResolver(), "screen_brightness_mode", 0, -3);
I tried ...ForUser methods with -2, -3 and 1000 UIDs - still the same error. Regular methods should use current process UID, so it's 1000 anyway.
No idea how it still knows that Xposed module is involved, code is supposed to be executed as if it's a part of a hooked app.
But I guess it knows) so clearing calling identity works perfectly, thanks.

I assume thread in screenTurnedOff you mentioned is your own you created? If yes, then for some reason thread in which runs phone window manager is thinking it's some kind of a foreign thread although created within phone window manager. Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.

C3C076 said:
Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.
Click to expand...
Click to collapse
screenTurnedOff is a stock method, it's called whenever it's called Definitely not from my module. I bet there is an explanation, something complicated)

Android N and new SELinux configuration.

First of all, I don't have a Nexus 5, but I have a Galaxy Tab Pro 8.4 with the same SoC and I think the N5 has the same issues with the new SELinux policy.
I'm having issues building Android 7.0 because of this SELinux rule: allow mediaserver system_file:file execmod;
Which is also needed on the N5.
Code:
# Grant access to Qualcomm MSM Interface (QMI) audio sockets to mediaserver
qmux_socket(mediaserver)
unix_socket_send(mediaserver, camera, camera)
unix_socket_send(mediaserver, mpdecision, mpdecision)
# Permit mediaserver to create sockets with no specific SELinux class.
# TODO: Investigate the specific type of socket.
allow mediaserver self:socket create_socket_perms;
[B]# For text relocations in /system/vendor/lib/libmmjpeg.so
allow mediaserver system_file:file execmod;[/B]
https://github.com/CyanogenMod/andr.../blob/staging/cm-14.0/sepolicy/mediaserver.te
When I try to build with it uncommented I get a neverallow error. The same rule is applied to other modules, so if I comment it out I can successfully build and boot, but many things don't work.
I don't know much about SELinux and I haven't found a way to bypass this rule without disabling SELinux. Maybe in this subforum someone can help me since there are already Nougat ROMs for the N5.
Thanks.

The sepolicy in bold was for text relocation as it commented. Bionic linker in Nougat has disallowed this feature, that's, all libraries must contain no text relocation section. So it was officially deprecated even in CM codes.
If you just want to bypass the build error, comment out disallow policy in externel/sepolicy to fix up the conflicts. But if you're wondering to get libmmjpeg.so working, go allow text relocation in bionic or find out the proper prebuilts (see bullhead).
BTW, This library is just for jpeg deconding/encoding. And of course it's not related to 'many things'.

[MODULE][MFW] - Android Messages For Web (Enabler)

Inspired by the recent post on the headlines describing how to enable Android Messages For Web by fiddling with some settings, I took and consolidated what I learned there, plus some other testing, into a handy-dandy Magisk Module that *should* work to enable MFW.
*HOWEVER*, I'm doing something wrong, and need a bit of help.
Repo is here:
https://github.com/d8ahazard/Magisk_Messages_For_Web
Basically, I'm just copying the sqlite binary to system, and then firing the commands to update some bools in a preference DB, then force-closing the messaging app so they take effect.
But for some reason, the script doesn't appear to be running. I'm trying to fire it in the services section. I can see that the bit where I'm setting permissions on sqlite3 is working, but I don't know why the sql commands aren't being executed.
Is there some way to output directly to the Magisk log from a module/script? I think if I can see what's happening there, I'd be set.
If I execute the service script manually in shell, it works:
Code:
marlin:/magisk/AMW # ./service.sh
Enabling Android Messages for Web (Hopefully)
Executing command '"UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%messaging%' AND name LIKE '%PhenotypeOverrideRollout%'"'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%messaging%' AND name LIKE '%bugle_phenotype__enable_multi_device%';'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%com.google.android.apps.messaging%' AND name LIKE '%MultiQueueRollout__launched__%';'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%com.google.android.apps.messaging%' AND name LIKE '%MultiDeviceRollout__launched__%';'
Command status is 0
Records updated successfully!
Restarting messaging app
I know I'm close...I just don't know what's missing!

Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !

julienbdx said:
Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !
Click to expand...
Click to collapse
Yeah, that is literally just adding one more line to my script, and would more than likely make the material redesign permanent.
At least, modifying the settings needed for MFW in db versus the phenotype.xml preferent makes MFW permanent. I'd assume the issue described in the theme thread is the exact same thing.
All I need is for someone to explain to me why the damned services.sh script isn't executing. I've even tried putting the commands in post-fs script instead...same thing. I add a line at the very end to 'touch /sdcard/hasMFW' so I know the script ran, but no 'hasMFW' file every shows up in /sdcard.
Someone...anybody...help?
@topjohnwu

julienbdx said:
Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !
Click to expand...
Click to collapse
There, I've pushed to git a version that has the commands that *should* enable material design as well.
Also, tried moving to post-fs.sh, still nothing works...
https://github.com/d8ahazard/Magisk_Messages_For_Web/commit/10319c338943d8b77b8c8523f31cc276bc4e5d23

Just FYI,
Modifying the flags table in PhenoType.db under GMS isn't permanent either (certainly better than a Shared_Prefs edit). It gets reset still. We're still trying to understand what causes it to reset.

MishaalRahman said:
Just FYI,
Modifying the flags table in PhenoType.db under GMS isn't permanent either (certainly better than a Shared_Prefs edit). It gets reset still. We're still trying to understand what causes it to reset.
Click to expand...
Click to collapse
That's good to know.
Ideally, if this would fire properly as a service, functionality would then be restored on reboot.
However, from what I'm seeing in my tests on my Pixel XL, with the values set the way I've done - I've not seen any breakage in functionality - even over numerous reboots.

digitalhigh said:
That's good to know.
Ideally, if this would fire properly as a service, functionality would then be restored on reboot.
However, from what I'm seeing in my tests on my Pixel XL, with the values set the way I've done - I've not seen any breakage in functionality - even over numerous reboots.
Click to expand...
Click to collapse
Yes, we've tested it too. It'll survive multiple reboots and FCs but eventually it reverts. We've narrowed it down to a service in GMS that checks every 24 hours.

MishaalRahman said:
Yes, we've tested it too. It'll survive multiple reboots and FCs but eventually it reverts. We've narrowed it down to a service in GMS that checks every 24 hours.
Click to expand...
Click to collapse
Interesting. What's the service name called? I've been poking around in the APK itself...
What I'm noticing is that my wife and a friend of mine both have Pixel 2 devices, and they "just have" the feature...which isn't all that surprising.
So, I'm wondering if the service is checking device props and enabling the feature that way. If so, then Magisk would again be an ideal candidate for fixing that issue.
LMK the service name, I'm no stranger to reversing smali.