Linux kernel has a feature to reclaim process memory by writing 1/2/3 to /proc/{pid}/reclaim as https://lwn.net/Articles/548431/. but when I check current Android source code, it not exist. So I am wondering if such feature has deprected or moved?
Finally I think I found the reason from the commit message:
https://android-review.googlesource.com/c/platform/frameworks/base/+/1730078
Edgar Arriaga Edgar Arriaga, a year ago (August 13th, 2020 4:03am)
Migrate to use process_madvise syscall instead of procfs interface for memory compaction
Currently the system uses procfs and we are migrating to use a syscall called process_madvise
which makes the code upstreamable and will allow for making compaction widely available for multiple
android devices.
It also opens room for future developments that involve a finer grain VMA compressions
than the current procfs allows.
Related
I am implementing an Android ODM system. I would like to create a VirtualDisplay constructed around an ImageReader so that the process providing the virtual display will receive the series of frames coming out of SurfaceFlinger as HardwareBuffer instances.
The intention is to fetch out the Linux dmabuf handle to each received HardwareBuffer by using AHardwareBuffer_fromHardwareBuffer() to get the corresponding native object, then convert it to an EGLImage with eglCreateNativeClientBufferANDROID() and then finally use eglExportDMABUFImageMESA() to obtain the dmabuf filedescriptor.
The critical piece of API -- AHardwareBuffer_fromHardwareBuffer() -- lives in the native library called "libandroid". Google documentation (see https://source.android.com/devices/architecture/images/vndk_design_android_o.pdf) explicitly indicates that vendor programs are prohibited from using API in libandroid.
This seems strange, because libandroid is already exposed in the application NDK. I think this means that backward portability in all future Android releases is therefore already demanded of libandroid.
Is there any existing way that I can make my vendor program link against this API? If not, could AHardwareBuffer_fromHardwareBuffer() be migrated out to the VNDK in a similar way as some of the other native C++ API's related to AHardwareBuffer have been?
Updated:
It's a pre-installed service that needs (in addition to doing these VirtualDisplay and ImageReader mechanics) to do some interaction with a custom HAL (so: not anything that implements one of the standard Google HIDL interfaces) that my customer is implementing.
I think that relegates us to needing to pre-install into the /vendor partition, right? I don't know whether this technically speaking makes me a "VNDK process", but the restriction against linking against libandroid kicks in anytime that I put "vendor: true" into the Blueprint file.
This pre-installed service sits in the AOSP tree because I'd like to sign it with the platform key so that the service can set its android:persistent property in AndroidManifest.xml to avoid it being subject to arbitrary shutdown from ActivityManager.
Other pre-installed applications will go badly if this VirtualDisplay doesn't end get instantiated. I'm uncertain what this means for GSI. Maybe you're likely to say that, with a GSI image installed for testing, none of those other preinstalled apps are present either so there's no problem.
Is this process a regular application (APK that provides Activities, Services, etc.) that just happens to be pre-installed on the device? I'd imagine it is if you're using VirtualDisplay and ImageReader. If so, there should be no problem using libandroid.
The restriction on libandroid is specifically for VNDK processes, i.e. lower level parts of the system. The restriction is there because several things in libandroid depend on the Android Framework, ART runtime, etc. as well as unversioned and non-fixed internal interfaces to them. So the usual versioning of VNDK-available libraries, where literally vndk binaries from old versions of the OS must work on newer versions of the OS, doesn't work for libandroid because of those dependencies on non-stable internal interfaces.
But if you're writing something that sits above the framework and is only using public APIs, then it's not a VNDK process and those restrictions don't apply.
(Note: I work on Android and have been involved in AHardwareBuffer APIs. But I'm not a VNDK expert nor an expert on the rules around vendor processes and vendor-preinstalled applications. So take this as reflecting my own personal understanding, and not an official statement from the Android team: if there's official documentation that contradicts what I've said, it's probably right and I'm wrong.)
I am trying to port the android kernel to a vendor SoC which is currently running the 2.6.35 kernel. I have looked for a while, and it seems that the only Google released kernels which are not made specifically for an existing device can be found here:
https://android.googlesource.com/kernel/common/+refs
The problem is that the oldest version they have there is 2.6.39. Is this there anywhere I can find older kernel versions which only have android specific material on them, or will I have to use this and settle the extra merging conflicts?
I am currently an intern (so I am new to all this..), and the last person in my position was apparently trying to merge the company kernel with something from ARM called "armdroid" (which has all the kernel versions):
http://linux-arm.org/git?p=armdroid.git;a=commit;h=3baa6a09028e75b210a659bc9b5c7631943edd44
This doesn't make sense though, because it looks like this kernel is designed to work with Realview and Versatile Express platforms, so trying to merge it with the code here would only cause more conflicts. No one here knows anything about android, and I can't get a good explanation as to why he was trying to use it.
For what I am trying to do, do you think that I should use the Google common kernel code, or could it be worth looking for a device specific kernel to merge with? And to repeat my main question, is there a way to get the older android kernel source code?
Thank you!
The 2.6.35 kernel was used by Gingerbread.
If there is no 'common' kernel, you have to use an old Samsung kernel and remove the Samsung-specific stuff.
Please note that 2.6.35 was released in 2010.
If that SoC cannot run a current kernel, you should not use it at all.
I am studying the different logging mechanisms on Linux in case of a Kernel panic (OOPS). So far from my search on the web, I have been able to derive the following information:
apanic was an old mechanism of getting the job done.
ram_console/persistent_ram is a new mechanism.
Could someone enlighten me about the following in this regard ?
What was the old apanic mechanism, at a high-level how did this work
?
Why was the apanic mechanism deprecated, in favor of the ram_console/persistent_ram mechanism ?
What advantages does the new ram_console/persistent_ram mechinsm bring to the table.
In what way is the ram_console/persistent_ram functionally different from the old apanic approach ?
I am just looking for pointers and high level answers, in some sense a direction which I can take to research the mechanisms further. I would appreciate any relevant information in this regard.
Thanks
Find answers below for your series of questions.
What was the old apanic mechanism, at a high-level how did this work?
It is a mechanism used by Android for message logging. It writes the log message into some specific offset in mtd partition of NAND. The kernel module exports file named called "apanic" to the "debugfs". The debugfs can be mounted on some directory using the below command. " mount -t debugfs none /sys/kernel/debug" which requires debugfs configuration enabled on linux kernel.
For more information on this go through the source code in link below.
https://android.googlesource.com/kernel/msm.git/+/android-msm-2.6.35/drivers/misc/apanic.c
Why was the apanic mechanism deprecated, in favor of the ram_console/persistent_ram mechanism ?
This apanic driver is not part of a linux kernel. It is specific to android. It is deprecated in latest version of androids. The reason could be writing into nand partition may not be good idea when kernel opps happens. Since the nand_write is slow as well as has limited write cycles. This is just my opinion. But i am not sure of the actual reason .
What advantages does the new ram_console/persistent_ram mechinsm bring to the table?
It is also a logging mechanism used by android for logging console messages. Here the logging messages goes into RAM area. In case of persistent_ram , the log messages goes to persistent memory area (which will be retained ) of RAM. This driver module creates a file named "last_kmsg" in the proc directory. This message can be read in next boot if the kernel oops and stops booting. For more information go through the source code given in the below link.
https://android.googlesource.com/kernel/common.git/+/android-3.4/drivers/staging/android/ram_console.c
In what way is the ram_console/persistent_ram functionally different from the old apanic approach ?
The former is ram based and the later is mtd based.
In the latest experimental android source i am not finding the source of both. Do not know the reason.
https://android.googlesource.com/kernel/common.git/+/experimental/android-3.10-rc5/drivers/staging/android/
Hope i clarified your queries.
Regards,
Yuvaraj.A
I'm about to port a large C++ project (some sort of Library Project, it contains absolutely no GUI) to Android. It's actually a Visual C++ project, but it will be ported to Linux as intermediate step. I know that Android is not a "full" Linux and does not claim to provide all POSIX functions, but I also know there are a lot of "POSIXish functions" on Android by using the NDK.
Now my actual question is:
Which are the biggest/most important functions that are NOT available on Android compared with the full POSIX set? So that I can keep that in mind when doing the porting from Visual C++ to Linux GCC.
I tried to find something on Google, but found nothing really helpful, just here and there some stuff that mentioned that there are some POSIX functions on Android...
Bionic a recode by Google. It is small but optimized for Android.
The only big thing I know of that it lacks is indeed the pthread_cancel() function.
My experience is that if you port it successfully to GNU/Linux, without pthread_cancel() calls, then you should be mostly ok.
BTW, what kind of library are you trying to build? What does it uses? Network, threads...
PS: Even Linux is not fully POSIX.
Bionic Wikipedia page
https://en.wikipedia.org/wiki/Bionic_(software)#Differences_from_POSIX
Also has some interesting info:
Although bionic aims to implement all of C11 and POSIX, there are still (as of Oreo) about 70 POSIX functions missing[8] from libc. There are also POSIX functions such as the endpwent/getpwent/setpwent family that are inapplicable to Android because it lacks a passwd database. As of Oreo, libm is complete.
Some functions deliberately do not conform to the POSIX or C standards for security reasons, such as printf which does not support the %n format string.[9]
Official Bionic in tree documentation quote
https://android.googlesource.com/platform/bionic/+/37ad9597839c70a7ec79578e5072df9c189fc830/docs/status.md
Run ./libc/tools/check-symbols-glibc.py in bionic/ for the current list of POSIX functions implemented by glibc but not by bionic. Currently (2017-10):
aio_cancel
aio_error
aio_fsync
aio_read
aio_return
aio_suspend
aio_write
lio_listio
pthread_cancel
pthread_mutex_consistent
pthread_mutex_getprioceiling
pthread_mutex_setprioceiling
pthread_mutexattr_getprioceiling
pthread_mutexattr_getprotocol
pthread_mutexattr_getrobust
pthread_mutexattr_setprioceiling
pthread_mutexattr_setprotocol
pthread_mutexattr_setrobust
pthread_setcancelstate
pthread_setcanceltype
pthread_testcancel
wordexp
wordfree
libm
Current libm symbols: https://android.googlesource.com/platform/bionic/+/master/libm/libm.map.txt
0 remaining missing POSIX libm functions.
The most obvious feature missing is pthread_cancel().
This blog has some additional details: http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html
Good overview of Bionic: https://android-platform.googlegroups.com/attach/0f8eba5ecb95c6f4/OVERVIEW.TXT?gda=HWJaO0UAAAB1RXoVyyH5sRXFfLYnAq48KOFqr-45JqvtfiaR6gxIj4Qe8cBqW3BaWdSUPWi_jHqO3f1cykW9hbJ1ju6H3kglGu1iLHeqhw4ZZRj3RjJ_-A&view=1&part=4
shared memory is also something you might find differently implemented in android. was hit hard while trying to work with shm_open and shm_unlink on android kernel. Android implements asynchronous shared memory (ashmem).
Does anyone know where I can find the list of system call that can be used in Android Mobile phones? I guess that looking to the kernel should work, but I cannot find any *.h or *.c with the declaration of them.
Best regards
You primarily want section 2 of the linux kernel manual pages.
Very little is unique to Android, the few gotchas being in the android docs (no sys-V IPC, AF_INET sockets won't work unless you are in the network group, etc). Most of the android additions are drivers (Binder, etc) and novel usage patterns (for example of user IDs) rather than actual syscalls.
If you actually need the syscall numbers you can find them in bionic/libc/SYSCALLS.TXT within the sources
You may want to check the Bionic sources for the system call list. Since, Bionic is the C-Library, that Android works off.
Try here
It is located in SYSCALLS.TXT file inside of libc directory under certain Android version. Example above is system call on Android 11.