[android-porting] how to disable JIT/AOT make ART run it the pure C++ interpreter mode
I just wonder if there have a way can config ART do C++ interpeter mode insteand of JIT or AOT ? THanks -- -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting --- You received this message because you are subscribed to the Google Groups "android-porting" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-porting+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/android-porting/bfd0c54e-0f74-40d4-be35-e10f125500e1%40googlegroups.com.
Re: [android-porting] Strange AVC Denial
On 07/13/2016 12:22 PM, Roman Mazur wrote: >>No, the denial is caused by the fact that the app is running with >>categories (c512,c768) and the file is not labeled with the same >>categories. You can allow this by adding the mlstrustedobject attribute >>to your type: > > Got it, thanks! > But speaking about the sharing scenario between apps, isn't it the same > case I have with my daemon (when it opens a file descriptor and passes > it to an app)? Why does it work for apps from different profiles/users? external/sepolicy/mls defines different constraints on app data files versus other files. For app data files, which are labeled with the same categories as the app process, we can impose a constraint on open that requires equivalence and omit constraints on read and write, thereby allowing passing and use of open file descriptors while blocking direct open of any file that has a different category set. For other files, we cannot do that without blocking any form of open to the file (even if only for read access) since it will not have the same categories; we instead use conventional MLS constraints on read and write, which will generally allow read access and prohibit write access (unless the file type is a mlstrustedobject). > > And thanks for the clarification regarding the audit message. > >>Wouldn't make more sense to make the daemon MLS aware and label these > files with the category set of the requestor? > > There are multiple apps that can access those files. And currently this > access is granted using Android permissions model (the daemon checks if > caller has the permission before opening a file). But my plan is to > define a custom domain for these apps that will be assigned basing on > application signature. And then use MLS to prevent sharing the files > with other apps. > Would you point me to an example of an MLS aware daemon? We generally would not create a MLS-aware daemon per se but instead just a SELinux-aware daemon. Examples in AOSP today include the init property service, servicemanager, keystore, debuggerd, and drmserver; they fetch the security context of their client via getpeercon or getpidcon, invoke SELinux permission checks via selinux_check_access, and possibly manage or lookup object security contexts of their own. -- -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting --- You received this message because you are subscribed to the Google Groups "android-porting" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-porting+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-porting] Strange AVC Denial
On 07/12/2016 11:57 AM, Roman Mazur wrote:
> I'm working on a custom build based on Android 6.0.1 for Nexus 7. This
> custom build adds a special daemon that is started from init.rc and
> exposes some API to applications. Particularly, one of available methods
> creates a new file at /data/daemon_dir and returns a file descriptor
> making it possible to write to this file from an app.
>
> The daemon has its own SELinux context (here it's named custom_daemon).
> And /data/daemon_dir has custom_daemon_file context. There are sepolicy
> rules that grant file creation to the daemon and file writes to
> untrusted_app.
>
> The configuration described above worked on Android 5. But after merging
> with Android 6, I'm getting the following denial:
>
> 07-11 21:57:46.735 13389-13389/? W/Binder_2: type=1400 audit(0.0:945):
> avc: denied { write } for path="/data/daemon_dir/some_file"
> dev="mmcblk0p30" ino=496817 scontext=u:r:untrusted_app:s0:c512,c768
> tcontext=u:object_r:custom_daemon_file:s0 tclass=file permissive=0
>
>
> Here are the rules that should allow the operation:
>
> allow untrusted_app custom_daemon_file:file rw_file_perms;
> allow untrusted_app custom_daemon_file:dir r_dir_perms;
(cc seandroid-list)
Assuming that you only want to allow apps to read and write files passed
to them explicitly by your daemon and not to directly open files in this
directory, you should only have:
allow untrusted_app custom_daemon_file:file { read write getattr };
In particular, you would not need to allow open permission to file nor
any permissions to the directory in this usage model, and not allowing
those permissions would be more secure as it would prevent apps from
directly accessing any of those files without going through your daemon.
> allow custom_daemon custom_daemon_file:dir create_dir_perms;
> allow custom_daemon custom_daemon_file:file create_file_perms;
>
>
> An interesting thing in this denial report is that scontext is
> untrusted_app. But the denial is logged for the daemon process (13389 is
> one of its thread IDs and Binder_2 is a name of the binder thread that
> handles the API call).
>
> I believe this mismatch is what is causing the denial but cannot
> understand why this happens and how this can be fixed.
No, the denial is caused by the fact that the app is running with
categories (c512,c768) and the file is not labeled with the same
categories. You can allow this by adding the mlstrustedobject attribute
to your type:
type custom_daemon_file, file_type, data_file_type, mlstrustedobject;
In 6.0, apps and their data files are assigned an automatically
generated category set (c512,c768 above) derived from their user ID in
order to isolate the processes and files of different users from each
other. This prevents cross-user or cross-profile access to /proc/pid
files and app data files, even if world-readable or -writable (sharing
is still possible by having the owning app open the file itself and pass
the file descriptor over binder or local socket IPC to another app, but
direct open is prohibited). This separation is currently applied to
untrusted apps and platform apps as a result of specifying
levelFrom=user in the seapp_contexts configuration.
With regard to the potentially misleading audit message, it is due to
the fact that this check occurs when your daemon tries to pass the open
file descriptor to the app, so it occurs while the daemon is the current
process. Before transferring the descriptor into the app's descriptor
table, SELinux checks whether the app is allowed to use it. So the
check is between the app's context and the file, but happens while the
daemon is still the current process.
--
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-porting+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[android-porting] Re: 3.1 Kernel for Tegra 2
The github for this kernel is here:
https://github.com/4ptiv4/Thrive-3.1_kernel/tree/jb_mr0
This is the specific branch. I have commented out the light sensor in my
for now to move past it and work out other errors so you will see that.
On Thursday, February 27, 2014 1:17:17 PM UTC-5, Stephen Proffitt wrote:
I know that there isn't an official 3.1 kernel for a Tegra 2 however, I've
started working on getting one ported, but I'm running into a snag with
drivers.
After working out GPIO issues, I'm having a problem with the light sensor
(isl29018 specifically). Every time I've tried to build, I get this error:
drivers/staging/iio/light/isl29018.c: In function 'isl29018_write_raw':
drivers/staging/iio/light/isl29018.c:356: error:
'IIO_CHAN_INFO_CALIBSCALE_SEPARATE' undeclared (first use in this function)
drivers/staging/iio/light/isl29018.c:356: error: (Each undeclared
identifier is reported only once
drivers/staging/iio/light/isl29018.c:356: error: for each function it
appears in.)
drivers/staging/iio/light/isl29018.c: In function 'isl29018_read_raw':
drivers/staging/iio/light/isl29018.c:396: error:
'IIO_CHAN_INFO_CALIBSCALE_SEPARATE' undeclared (first use in this function)
drivers/staging/iio/light/isl29018.c: At top level:
drivers/staging/iio/light/isl29018.c:415: error:
'IIO_CHAN_INFO_CALIBSCALE_SEPARATE' undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:426: error: expected ')' before '('
token
drivers/staging/iio/light/isl29018.c:427: error: expected ')' before
string constant
drivers/staging/iio/light/isl29018.c:428: error: expected ')' before
string constant
drivers/staging/iio/light/isl29018.c:429: error: expected ')' before '('
token
drivers/staging/iio/light/isl29018.c:432: error: expected ')' before '('
token
drivers/staging/iio/light/isl29018.c:439: error: 'iio_dev_attr_range'
undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:439: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:439: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:439: error: initializer element is
not constant
drivers/staging/iio/light/isl29018.c:439: error: (near initialization for
'isl29018_attributes[0]')
drivers/staging/iio/light/isl29018.c:440: error:
'iio_const_attr_range_available' undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:440: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:440: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:440: error: initializer element is
not constant
drivers/staging/iio/light/isl29018.c:440: error: (near initialization for
'isl29018_attributes[1]')
drivers/staging/iio/light/isl29018.c:441: error:
'iio_dev_attr_adc_resolution' undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:441: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:441: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:441: error: initializer element is
not constant
drivers/staging/iio/light/isl29018.c:441: error: (near initialization for
'isl29018_attributes[2]')
drivers/staging/iio/light/isl29018.c:442: error:
'iio_const_attr_adc_resolution_available' undeclared here (not in a
function)
drivers/staging/iio/light/isl29018.c:442: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:442: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:442: error: initializer element is
not constant
drivers/staging/iio/light/isl29018.c:442: error: (near initialization for
'isl29018_attributes[3]')
drivers/staging/iio/light/isl29018.c:443: error:
'iio_dev_attr_proximity_on_chip_ambient_infrared_supression' undeclared
here (not in a function)
drivers/staging/iio/light/isl29018.c:443: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:443: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:443: error: initializer element is
not constant
drivers/staging/iio/light/isl29018.c:443: error: (near initialization for
'isl29018_attributes[4]')
make[4]: *** [drivers/staging/iio/light/isl29018.o] Error 1
make[3]: *** [drivers/staging/iio/light] Error 2
make[2]: *** [drivers/staging/iio] Error 2
make[1]: *** [drivers/staging] Error 2
make: *** [drivers] Error 2
I've looked over the file and all previous code blocks and there is
nothing missing. I've been looking over the board files and it seems to my
untrained eyes that the functions
[android-porting] 3.1 Kernel for Tegra 2
I know that there isn't an official 3.1 kernel for a Tegra 2 however, I've
started working on getting one ported, but I'm running into a snag with
drivers.
After working out GPIO issues, I'm having a problem with the light sensor
(isl29018 specifically). Every time I've tried to build, I get this error:
drivers/staging/iio/light/isl29018.c: In function 'isl29018_write_raw':
drivers/staging/iio/light/isl29018.c:356: error:
'IIO_CHAN_INFO_CALIBSCALE_SEPARATE' undeclared (first use in this function)
drivers/staging/iio/light/isl29018.c:356: error: (Each undeclared
identifier is reported only once
drivers/staging/iio/light/isl29018.c:356: error: for each function it
appears in.)
drivers/staging/iio/light/isl29018.c: In function 'isl29018_read_raw':
drivers/staging/iio/light/isl29018.c:396: error:
'IIO_CHAN_INFO_CALIBSCALE_SEPARATE' undeclared (first use in this function)
drivers/staging/iio/light/isl29018.c: At top level:
drivers/staging/iio/light/isl29018.c:415: error:
'IIO_CHAN_INFO_CALIBSCALE_SEPARATE' undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:426: error: expected ')' before '('
token
drivers/staging/iio/light/isl29018.c:427: error: expected ')' before string
constant
drivers/staging/iio/light/isl29018.c:428: error: expected ')' before string
constant
drivers/staging/iio/light/isl29018.c:429: error: expected ')' before '('
token
drivers/staging/iio/light/isl29018.c:432: error: expected ')' before '('
token
drivers/staging/iio/light/isl29018.c:439: error: 'iio_dev_attr_range'
undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:439: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:439: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:439: error: initializer element is not
constant
drivers/staging/iio/light/isl29018.c:439: error: (near initialization for
'isl29018_attributes[0]')
drivers/staging/iio/light/isl29018.c:440: error:
'iio_const_attr_range_available' undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:440: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:440: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:440: error: initializer element is not
constant
drivers/staging/iio/light/isl29018.c:440: error: (near initialization for
'isl29018_attributes[1]')
drivers/staging/iio/light/isl29018.c:441: error:
'iio_dev_attr_adc_resolution' undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:441: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:441: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:441: error: initializer element is not
constant
drivers/staging/iio/light/isl29018.c:441: error: (near initialization for
'isl29018_attributes[2]')
drivers/staging/iio/light/isl29018.c:442: error:
'iio_const_attr_adc_resolution_available' undeclared here (not in a
function)
drivers/staging/iio/light/isl29018.c:442: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:442: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:442: error: initializer element is not
constant
drivers/staging/iio/light/isl29018.c:442: error: (near initialization for
'isl29018_attributes[3]')
drivers/staging/iio/light/isl29018.c:443: error:
'iio_dev_attr_proximity_on_chip_ambient_infrared_supression' undeclared
here (not in a function)
drivers/staging/iio/light/isl29018.c:443: error: request for member
'dev_attr' in something not a structure or union
drivers/staging/iio/light/isl29018.c:443: error: request for member 'attr'
in something not a structure or union
drivers/staging/iio/light/isl29018.c:443: error: initializer element is not
constant
drivers/staging/iio/light/isl29018.c:443: error: (near initialization for
'isl29018_attributes[4]')
make[4]: *** [drivers/staging/iio/light/isl29018.o] Error 1
make[3]: *** [drivers/staging/iio/light] Error 2
make[2]: *** [drivers/staging/iio] Error 2
make[1]: *** [drivers/staging] Error 2
make: *** [drivers] Error 2
I've looked over the file and all previous code blocks and there is nothing
missing. I've been looking over the board files and it seems to my
untrained eyes that the functions are being called properly, but obviously
something is wrong. Any ideas?
--
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
android-porting group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[android-porting] Porting a GS3 kernel to another GS3
Basically what I am trying to do is build a kernel that has configs for one variant of the Galaxy S3 (d2usc) for another Galaxy S3 (d2cri) which they are both essentially the same model, but the kernels are not inter changeable. My question is, what device specific code needs to be added or changed in the kernel source to make it work? Also, what is the preferred method to build a defconfig for my device that matches the one from the other device? -- -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting --- You received this message because you are subscribed to the Google Groups android-porting group. To unsubscribe from this group and stop receiving emails from it, send an email to android-porting+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-porting] Problem with removing stock android applications from Android code
On 02/04/2013 11:31 PM, Phani A wrote: Hi, I am trying to customize android build by removing few stock android applications from code and recompile the code. When I try to remove the Calculator application (by renaming Android.mk in packages/apps/Calculator/ folder), I am getting the following build error in ICS, make: *** No rule to make target `out/target/common/obj/APPS/Calculator_intermediates/classes.jar', needed by `out/target/common/obj/APPS/CalculatorTests_intermediates/classes-full-debug.jar'. Stop. Can anyone please help on how to resolve this error. Is there any cleaner way of excluding Android stock applications (such as Email, Calender, Calculator) ? Thanks in advance for any suggestion Phani Remove Calculator from PRODUCT_PACKAGES in the relevant build/target/product/*.mk files. -- -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting --- You received this message because you are subscribed to the Google Groups android-porting group. To unsubscribe from this group and stop receiving emails from it, send an email to android-porting+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[android-porting] Re: Debugging Dalvik start-up / JarVerifier problem on x86-64 Linux build
The debugger support in the VM will wait a second or two for the debugger to settle before continuing if you use android.os.Debug.waitForDebugger(). That's not enough to enter breakpoints by hand, but if you use a more sophisticated program like Eclipse it gives the debugger enough time to set breakpoints before resuming. Ah, cool -- sounds useful. That was the reminder I needed to move to the Eclipse front-end anyhow, and has helped -- thanks! That does look peculiar. I would guess the JNIEnv is bogus, and you're looking at a bunch of memory that isn't actually holding a JNI function table. Indeed, silly me -- the stack seems to be corrupt. I have now sidestepped this whole problem by commenting out the jar verification process (the initial exceptions were complaining about failing to find public keys, before being turned into other exceptions with a less helpful message -- I guess I need to install Android public keys locally for the Jars to verify? not sure why they're not in the distribution, but no matter). The fun's not over yet -- getting even stranger segfaults (without non-stop gdb) in some native calls originating in SystemServer (calling sqlite stuff). I might post back about those once I've investigated. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
[android-porting] Re: Debugging Dalvik start-up / JarVerifier problem on x86-64 Linux build
?)
(gdb) frame 1
#1 0x001f790a in _JNIEnv::CallStaticVoidMethod (this=0xf6fe1090,
clazz=0xf6acce14, methodID=0xf6fe0f58)
at dalvik/libnativehelper/include/nativehelper/jni.h:793
793 functions-CallStaticVoidMethodV(this, clazz,
methodID, args);
(gdb) print *this
$1 = {functions = 0xf6fa6360}
(gdb) print this-functions
$2 = (const JNINativeInterface *) 0xf6fa6360
(gdb) print *this-functions
$3 = {reserved0 = 0xf6fa6360, reserved1 = 0x0, reserved2 = 0x0,
reserved3 = 0x0, GetVersion = 0, DefineClass = 0, FindClass =
0xf68d675e,
FromReflectedMethod = 0, FromReflectedField = 0x30011,
ToReflectedMethod = 0x5026, GetSuperclass = 0x8062d68,
IsAssignableFrom = 0x7, ToReflectedField = 0, Throw = 0x1, ThrowNew
= 0x14,
ExceptionOccurred = 0, ExceptionDescribe = 0, ExceptionClear =
0x,
FatalError = 0xf6fa6558, PushLocalFrame = 0, PopLocalFrame = 0,
NewGlobalRef = 0, DeleteGlobalRef = 0x4, DeleteLocalRef =
0xf6a4b948,
IsSameObject = 0x15, NewLocalRef = 0xf6a4b9a0, EnsureLocalCapacity =
0x3a,
AllocObject = 0xf6a4bde8, NewObject = 0x44, NewObjectV =
0xf6a4c9b8,
NewObjectA = 0x4, GetObjectClass = 0xf6a4cad0, IsInstanceOf = 0x5,
GetMethodID = 0xf6a4caf8, CallObjectMethod = 0x3, CallObjectMethodV
= 0x3,
CallObjectMethodA = 0xf6a4b960, CallBooleanMethod = 0xe000,
CallBooleanMethodV = 0xf68bf2e8, CallBooleanMethodA = 0x1,
CallByteMethod = 0xf6fa6360, CallByteMethodV = 0xf694afeb,
CallByteMethodA = 0xf68d1e65, CallCharMethod = 0x1a,
CallCharMethodV = 0xd9bf9553, CallCharMethodA = 0x2c7e5503,
CallShortMethod = 0, CallShortMethodV = 0x13b,
CallShortMethodA = 0xf6fa6360, CallIntMethod = 0,
CallIntMethodV = 0xf6fb6a78, CallIntMethodA = 0, CallLongMethod =
0,
CallLongMethodV = 0, CallLongMethodA = 0xf68d75d9, CallFloatMethod =
0,
CallFloatMethodV = 0x30001, CallFloatMethodA = 0x5000,
CallDoubleMethod = 0x8062d68, CallDoubleMethodV = 0x7,
CallDoubleMethodA = 0, CallVoidMethod = 0x1, CallVoidMethodV =
0x50,
CallVoidMethodA = 0, CallNonvirtualObjectMethod = 0,
CallNonvirtualObjectMethodV = 0x,
CallNonvirtualObjectMethodA = 0xf6fa6558,
CallNonvirtualBooleanMethod = 0,
CallNonvirtualBooleanMethodV = 0, CallNonvirtualBooleanMethodA = 0,
CallNonvirtualByteMethod = 0x1, CallNonvirtualByteMethodV =
0xf6a43008,
CallNonvirtualByteMethodA = 0x18, CallNonvirtualCharMethod =
0xf6a43158,
CallNonvirtualCharMethodV = 0x21, CallNonvirtualCharMethodA =
0xf6a43640,
CallNonvirtualShortMethod = 0x2b, CallNonvirtualShortMethodV =
0xf6a44010,
CallNonvirtualShortMethodA = 0x1, CallNonvirtualIntMethod =
0xf6a440c8,
CallNonvirtualIntMethodV = 0x1, CallNonvirtualIntMethodA =
0xf6a440d8,
CallNonvirtualLongMethod = 0x10, CallNonvirtualLongMethodV = 0xa,
CallNonvirtualLongMethodA = 0xf6a43010,
CallNonvirtualFloatMethod = 0xffc0,
CallNonvirtualFloatMethodV = 0xf69104bc, CallNonvirtualFloatMethodA
= 0x6,
CallNonvirtualDoubleMethod = 0xf6fa6420,
CallNonvirtualDoubleMethodV = 0xf68fcc3d,
CallNonvirtualDoubleMethodA = 0xf68ce671, CallNonvirtualVoidMethod =
0x19,
CallNonvirtualVoidMethodV = 0xa, CallNonvirtualVoidMethodA =
0xf6fa6420,
GetFieldID = 0xf6fa6420, GetObjectField = 0xf68fd08b,
GetBooleanField = 0xf68ce671, GetByteField = 0x19, GetCharField =
0x1,
GetShortField = 0xf6fa6420, GetIntField = 0xf6fa6420,
GetLongField = 0xf68fde98, GetFloatField = 0xf68ce671,
GetDoubleField = 0x1a, SetObjectField = 0xf4240,
SetBooleanField = 0xf6fa6420, SetByteField = 0xf6fa6420,
SetCharField = 0xf68fe29b, SetShortField = 0xf68ce671, SetIntField =
0x19,
SetLongField = 0x5, SetFloatField = 0xf6fa6420, SetDoubleField =
0xf6fa6420,
GetStaticMethodID = 0xf6922173, CallStaticObjectMethod =
0xf68ce671,
CallStaticObjectMethodV = 0xa, CallStaticObjectMethodA = 0x5,
CallStaticBooleanMethod = 0, CallStaticBooleanMethodV = 0xf6fa6420,
CallStaticBooleanMethodA = 0xf6924052, CallStaticByteMethod =
0xf68d75ac,
CallStaticByteMethodV = 0xa, CallStaticByteMethodA = 0,
CallStaticCharMethod = 0, CallStaticCharMethodV = 0,
CallStaticCharMethodA = 0xab, CallStaticShortMethod = 0xf6fa6360,
CallStaticShortMethodV = 0, CallStaticShortMethodA = 0,
CallStaticIntMethod = 0, CallStaticIntMethodV = 0,
CallStaticIntMethodA = 0,
---Type return to continue, or q return to quit---q
CQuit
(gdb) print *this-functions-CallStaticVoidMethodV
Cannot access memory at address 0x0
I'll keep digging on this one... I can confirm that at the same point
when not in non-stop
mode, all the function pointers look sane. The pause hack will
probably be enough to
get me going anyway. But as always, thanks for any suggestions!
Stephen
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
[android-porting] Debugging Dalvik start-up / JarVerifier problem on x86-64 Linux build
Hi, Can someone give me tips about how to debug Dalvik start-up? I'm trying to attach jdb to the VM as early as I can, to debug some JarVerifier problems on start-up of the Android runtime. But this causes Heisenbergian assertion failures (i.e. that I don't see when not debugging). This is a build of Android for my desktop x86-64 machine running FC13. (Quick summary: I'm resurrecting the sim build, for my own sinister purposes that you can ask me about if you like.) If I attach jdb before the InvokeStaticMethod that calls main, it causes an assertion failure. Alternatively, if you can tell why the verification is failing, I can maybe live without being able to attach the debugger early! This is the error I'm trying to debug. W/PackageParser(26345): Exception reading AndroidManifest.xml in /home/ scratch/skell/android-platform-built-gcc/out/host/linux-x86/pr/sim/ system/framework/framework-res.apk: java.lang.SecurityException: /home/ scratch/skell/android-platform-built-gcc/out/host/linux-x86/pr/sim/ system/framework/framework-res.apk failed verification of META-INF/ CERT.SF W/PackageParser(26345): java.lang.SecurityException: /home/scratch/ skell/android-platform-built-gcc/out/host/linux-x86/pr/sim/system/ framework/framework-res.apk failed verification of META-INF/CERT.SF W/PackageParser(26345): at java.util.jar.JarVerifier.failedVerification(JarVerifier.java:135) W/PackageParser(26345): at java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:312) W/PackageParser(26345): at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:265) W/PackageParser(26345): at java.util.jar.JarFile.getInputStream(JarFile.java:389) W/PackageParser(26345): at android.content.pm.PackageParser.loadCertificates(PackageParser.java: 343) W/PackageParser(26345): at android.content.pm.PackageParser.collectCertificates(PackageParser.java: 491) W/PackageParser(26345): at com.android.server.PackageManagerService.collectCertificatesLI(PackageManagerService.java: 2570) W/PackageParser(26345): at com.android.server.PackageManagerService.scanPackageLI(PackageManagerService.java: 2656) W/PackageParser(26345): at com.android.server.PackageManagerService.scanDirLI(PackageManagerService.java: 2514) W/PackageParser(26345): at com.android.server.PackageManagerService.init(PackageManagerService.java: 930) W/PackageParser(26345): at com.android.server.PackageManagerService.main(PackageManagerService.java: 694) W/PackageParser(26345): at com.android.server.ServerThread.run(SystemServer.java:149) E/PackageParser(26345): Package android has no certificates at entry AndroidManifest.xml; ignoring! W/PackageManager(26345): Failed verifying certificates for package:android If I break the dalvikvm in gdb before it does Check_CallStaticVoidMethodV, then attach jdb and resume both, I get the following. E/dalvikvm(26824): ASSERT FAILED (dalvik/vm/Thread.c:3160): oldStatus ! = THREAD_RUNNING Program received signal SIGSEGV, Segmentation fault. 0x00ad97fb in dvmChangeStatus (self=0x8056820, newStatus=THREAD_RUNNING) at dalvik/vm/Thread.c:3160 3160assert(oldStatus != THREAD_RUNNING); ... whereas if I step through the main call from gdb, the assertion checks okay. I've tried a few variations on that theme too, attaching the debugger at various points. But they always trigger the assertion failure. It seems like attaching jdb does something to thread statuses that dvmChangeStatus assumes will never happen. This is all on dalvikvm build from the current-ish Android tree (checked out in May) . Thanks for any suggestions! Let me know what extra information I can provide Stephen -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
[android-porting] Re: why in emulator, /dev/eac is connected with the audio?
hi Max have you find the answer? how /dev/eac is connected with host linux's sound system? I am trying to add my own device driver to android On Apr 18, 4:02 pm, max max.xi...@gmail.com wrote: Hi David, Thanks for your reply. When I study the code in frameworks\base\libs\audioflinger \AudioHardwareGeneric.cpp, I saw it does open the device node dev/ eac to get a File descriptor. Therefore , the question is how /dev/ eac is connected with the host linux's sound system. I have read the code in external/qemu/hw/goldfish_audio.c, but I still can not figure out how the device node /dev/eac in emulator's linux system is connected with host linux's sound system. Thanks On Apr 17, 5:48 pm, David Turner di...@android.com wrote: On Fri, Apr 17, 2009 at 10:51 AM, max max.xi...@gmail.com wrote: Hi Buddies, I wanna get understood that why in emulator dev/eac is the device of audio, historical reason, but mostly because that's what the emulator-specific kernel supports as I know, in external/qemu/audio, there is all kinds audio drivers, such as oss, alsa, these are only used to send audio output to the host sound system, this has nothing to do with what is supported in the emulated system. These are not 'drivers' by the way, just usual call to sound libraries / system interfaces you can have a look at external/qemu/hw/goldfish_audio.c to see the code used to support sound hardware emulation in Android but I am very curious why in the android linux system, the dev/eac is connected with those drivers. Anybody can give me some light on that? Max- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting -~--~~~~--~~--~--~---
