100% agree with Jon.

It's because of these fundamental problems that we removed support for the
SecurityManager in Android. If you attempt to set a security manager in
Android, it will throw a SecurityException.

http://developer.android.com/reference/java/lang/System.html#setSecurityManager(java.lang.SecurityManager)

    public static void setSecurityManager(SecurityManager sm) {
        if (sm != null) {
            throw new SecurityException();
        }
    }

-- Nick

On Fri, Mar 2, 2012 at 8:16 AM, Jon Larimer <[email protected]> wrote:

> It's simply not possible to prevent applications from inspecting variables
> inside of a library that's loaded into their own process. Since there's no
> default SecurityManager, an app could use reflection to modify the
> protection flags on a class, method, or field (i.e., change a private field
> to public, then read or modify it). Even if there was a SecurityManager,
> there's nothing blocking an app from directly accessing process memory
> through native code to read or modify class instance data in memory.
>
> The only way to provide a "secure" API that can't be modified by an app is
> to implement the API as a separate service. Since a service can run in a
> separate process with it's own UID, you can prevent other apps using the
> API from modifying any of the internal structures. Doing this requires
> having a separate APK file for the API service. The APK will need to be
> installed separately by the user who installs the app that uses it.
>
> This can be a pain for users, but it's not without precedent - Adobe AIR
> works like this. An app that uses AIR needs to ask the user to install AIR
> separately from the Android Market before they can use the app.
>
> -jon
>
>
> On Thu, Mar 1, 2012 at 11:02 PM, Subbu Srinivasan 
> <[email protected]>wrote:
>
>> I want to build a Java library and give to developer community to develop
>> Android app. Now how can I prevent the user from looking at run time
>> variables inside the library.
>> We do have standard Java protection mechanisms, but how can we make the
>> solution fool proof.
>>
>> Thanks
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Android Security Discussions" group.
>> To post to this group, send email to
>> [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/android-security-discuss?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Android Security Discussions" group.
> To post to this group, send email to
> [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/android-security-discuss?hl=en.
>



-- 
Nick Kralevich | Android Security | [email protected] | 650.214.4037

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.

Reply via email to