Modifying Android UI through linux kernel - android

My goal is to show a popup window in the Android UI using linux kernel. Is it possible to do so? I checked the SDM driver(DRM driver for QCOM/adreno devices) but I couldn't find an API which does so. I thought of a solution which would be to open app that shows a pop up on screen but I couldn't find an api for starting android apps from the kernel either. I was able to find some information in this thread How to start an app from kernel
However I couldn't find any solid information!
EDIT
I tried launching telegram as a test through am (and I bypassed selinux denial as well) but nothing happened. Here's the code:
static int launch_test(void){
char *envp[] = {
"ANDROID_DATA=/data",
"LOGNAME=shell",
"HOME=/",
"ANDROID_STORAGE=/storage",
"ANDROID_ASSETS=/system/app",
"SHELL=/system/bin/sh",
"EXTERNAL_STORAGE=/sdcard",
"ANDROID_CACHE=/cache",
"USER=shell",
"TMPDIR=/data/local/tmp",
"PATH=/sbin:/system/sbin:/system/bin:/system/xbin:/odm/bin:/vendor/bin:/vendor/xbin",
NULL};
char *argv[] = {"/system/bin/am", "start", "org.telegram.messenger/org.telegram.ui.LaunchActivity", NULL};
return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
}

Related

Native network-related functions randomly blocking in android

I have a library written in C that I'm using from an Android application. I discovered that the application blocks sometimes while executing various functions (what is common is they are all related to networking).
I'm testing on a real Android device running Android 6.
The library is compiled with NDK version 21.
So far I have observed this behavior with 3 functions - getaddrinfo, poll and socket:
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
getaddrinfo(hostname, port, &hints, &result);
////
struct pollfd wait = {
.fd = fd,
.events = event,
.revents = 0
};
status = poll(&wait, 1, 10000);
////
fd = socket(result->ai_family, result->ai_socktype, result->ai_protocol);
These functions are called several times each after the program starts running. The same call can work fine one time and block indefinitely (at least several minutes) the next time. The internet connection on the device seems to be fine.
Any ideas? How can I even approach debugging such a problem?
I didn't actually find the reason for the problem, but I found how to fix it. Part of the code was written by somebody else and I wasn't sure what exactly it was doing. After rewriting this part, everything started to work fine.
Among other things, the code was spawning a new process with fork(). I suspect the problem to be related to that.

reading /proc/meminfo from adobe air android app

So if I pop open a command prompt and take a peek at my device's /proc/meminfo, like so:
adb shell cat /proc/meminfo
I get back what you'd expect - a nice long list of data on the device's RAM usage + capacity. But when I try to read that same location from an adobe air android app, using this basic code:
var meminfo:File = new File().resolvePath('/proc/meminfo');
meminfo.addEventListener(Event.COMPLETE, function(e:Event):void {
trace(File(e.target).data);
});
meminfo.load();
... I get nothing, just an empty ByteArray.
So why can I see the contents of /proc/meminfo from the adb shell, but not from the app? Same goes for other stuff in the /proc/ directory - cpuinfo, for instance. I have no problem loading an xml file from the /etc/ directory, though.
It turns out that if you copy memtest (or cputest, etc.) out to another location, somewhere a little friendlier to AIR - say, File.documentsDirectory - then everything goes smoothly.
Your code might look a little like this:
var meminfo_original:File = new File().resolvePath('/proc/meminfo');
var meminfo_copy:File = File.documentsDirectory.resolvePath('meminfo.txt');
meminfo_original.copyTo(meminfo_copy, true);
meminfo_copy.addEventListener(Event.COMPLETE, function(e:Event):void {
trace(File(e.target).data.toString());
});
meminfo_copy.load();

Does android support the PTRACE_SINGLESTEP?

OK, this is a simple question.Does android support the PTRACE_SINGLESTEP when I use ptrace systemcall? when I want to ptrace a android apk program, I find that I can't process the SINGLESTEP trace. But the situation changed when I use the PTRACE_SYSCALL, It can work perfectly. Does the android wipe out this function or arm lack some supports in hardware? Any help will be appreciated!thanks.
this is my core program:
int main(int argc, char *argv[])
{
if(argc != 2) {
__android_log_print(ANDROID_LOG_DEBUG,TAG,"please input the pid!");
return -1;
}
if(0 != ptrace(PTRACE_ATTACH, target_pid, NULL, NULL))
{
__android_log_print(ANDROID_LOG_DEBUG,TAG,"ptrace attach error");
return -1;
}
__android_log_print(ANDROID_LOG_DEBUG,TAG,"start monitor process :%d",target_pid);
while(1)
{
wait(&status);
if(WIFEXITED(status))
{
break;
}
if (ptrace(PTRACE_SINGLESTEP, target_pid, 0, 0) != 0)
__android_log_print(ANDROID_LOG_DEBUG,TAG,"PTRACE_SINGLESTEP attach error");
}
ptrace(PTRACE_DETACH, target_pid, NULL, NULL);
__android_log_print(ANDROID_LOG_DEBUG,TAG,"monitor finished");
return 0;
}
I run this program on shell. And I can get the root privilege.
If I change the request to PTRACE_SYSCALL the program will run normally.
But if the request is PTRACE_SINGLESTEP, the program will get an error!
PTRACE_SINGLESTEP has been removed on ARM Linux since 2011, by this commit.
The HW has no support for single-stepping; previous kernel support involved decoding the instruction to figure out which one's next (branches) and temporarily replacing it with a debug-break software breakpoint.
Quoting a mailing list message about the same commit, describing the old situation: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041324.html
PTRACE_SINGLESTEP is a ptrace request designed to offer single-stepping
support to userspace when the underlying architecture has hardware
support for this operation.
On ARM, we set arch_has_single_step() to 1 and attempt to emulate
hardware single-stepping by disassembling the current instruction to
determine the next pc and placing a software breakpoint on that
location.
Unfortunately this has the following problems:
Only a subset of ARMv7 instructions are supported
Thumb-2 is unsupported
The code is not SMP safe
We could try to fix this code, but it turns out that because of the
above issues it is rarely used in practice. GDB, for example, uses
PTRACE_POKETEXT and PTRACE_PEEKTEXT to manage breakpoints itself and
does not require any kernel assistance.
This patch removes the single-step emulation code from ptrace meaning
that the PTRACE_SINGLESTEP request will return -EIO on ARM. Portable
code must check the return value from a ptrace call and handle the
failure gracefully.
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
The comments I received about v1 suggest that:
If emulation is required, it is plausible to do it from userspace
ltrace uses the SINGLESTEP call (conditionally at compile-time since other architectures, such as mips, do not support this
request) but does not check the return value from ptrace. This is a
bug in ltrace.
strace does not use SINGLESTEP

how to register a device driver with android/linux power driver?

I am working on a lcd related kernel level device driver for a android device. Can someone please help me with power management related APIs in Android through which I can register my driver to recieve any changes in device state.
To be more precise I want my driver to recieve any events from power driver(or is there something else) in case when the system state changes, for example from running state to sleep state or suspend state. I would want my driver also to sleep which in current scenario is eating up all the battery..
I have got few links http://www.kandroid.org/online-pdk/guide/power_management.html
and http://developer.android.com/reference/android/os/PowerManager.html
which talks about functions like android_register_early_suspend and android_register_early_resume but I could not find any call to these functions in my entire kernel source code (based on linux 3.0)
I have heard of "Linux Power Management" and can find folders like drivers/base/power and drivers/power in my current baseline code. How can I use this driver in my code.
Please let me know if I am missing with any details.
Any help would be highly appreciated.
Your Driver should implement Runtime suspend/resume callbacks. Check this doc.
sample code to implement Device PM callbacks in 'struct dev_pm_ops' (as defined in linux/pm.h)
static int lcdxxx_suspend(struct device *dev)
{
//Your Code to suspend your device
}
static int lcdxxx_resume(struct device *dev)
{
//Your code to resume your device
}
static const struct dev_pm_ops lcd_pm_ops = {
.suspend = lcdxxx_suspend,
.resume = lcdxxx_resume,
};
struct device_driver lcd_driver = {
....
.pm = &lcd_pm_ops,
....
}
This is just sample impl. Real Implementation depends on your requirements.

Embed 3th party activity in my Activity

I'm using the following code to get the activity of a 3th party application and to put it in my activity:
LocalActivityManager mgr = getLocalActivityManager();
Intent i = new Intent(this, SomeActivity.class);
Window w = mgr.startActivity("unique_per_activity_string", i);
View wd = w != null ? w.getDecorView() : null;
if(wd != null) {
mSomeContainer.addView(wd);
}
Copyright Synic: android: using ActivityGroup to embed activities
However, due Security Restrictions, I'm receiving the following error:
java.lang.SecurityException: Requesting code from com.google.android.youtube (with uid 10065) to be run in process com.xxx.xxx (with uid 10144). (It is possible to show your own activity with your own SharedUID from your own application.)
Now i'm wondering if there is any way I can avoid this. By using rooted devices(?), bug in Android OS, or anything else. If I can get it to work by rooting my device, how would i achieve it? (not the rooting ofc)
I'm using the following code to get the activity of a 3th party application and to put it in my activity
That is not supported, sorry.
Now i'm wondering if there is any way I can avoid this.
You are welcome to grab the source code to Android, modify it to suit, put your altered OS into your own modded ROM, and install that ROM mod on whatever devices you are able to.

Categories

Resources