I thought FallbackCheckinService extends ICheckinService.Stub
(android.os), which already implements masterClear() as a "remote"
transaction.  I am unable to determine what actually executes this
TRANSACTION_masterClear.  Can someone help?  Is there an RPC component
that somehow then invokes the wipe exec in /system/bin?
Rgds

On Feb 6, 9:46 am, Dianne Hackborn <[email protected]> wrote:
> The code should be refactored, to separate these.
>
> Settings can't call it directly because it is running in another process
> that can't do this itself.
>
>
>
>
>
> On Fri, Feb 6, 2009 at 8:08 AM, Dave <[email protected]> wrote:
>
> > Thanks again Diane.
>
> > Perhaps you or someone could explain what master clear has to do with
> > the checkinservice or why the settings application wasn't directly
> > calling the recoveryservice?   I assume that there is something other
> > than a "Fallback" checkin service on the G1 - though there doesn't
> > seem to be an obvious extension other than a hardcoded change in the
> > systemserver.java to change this.
>
> > On Feb 5, 6:55 pm, Dianne Hackborn <[email protected]> wrote:
> > > Ah it was added very recently.  It will be in the repo at some point,
> > sorry
> > > about that.
>
> > > On Thu, Feb 5, 2009 at 4:32 PM, Dave <[email protected]> wrote:
>
> > > > Thanks Dianne,
> > > > is this com.android.internal.os.RecoverySystem.rebootAndWipe()
> > > > something that also needs to be created?  I don't see that in my repo
>
> > > > On Feb 5, 6:14 pm, Dianne Hackborn <[email protected]> wrote:
> > > > > Ah sorry, I didn't realize about that.  The implementation just calls
> > > > > com.android.internal.os.RecoverySystem.rebootAndWipe(), after
> > checking
> > > > the
> > > > > appropriate permission:
>
> > > > >         public void masterClear() {
> > > > >             if
> > > > > (checkCallingOrSelfPermission("android.permission.MASTER_CLEAR") !=
> > > > >                     PackageManager.PERMISSION_GRANTED) {
> > > > >                 Log.e(TAG, "Permission Denial: can't invoke
> > masterClear
> > > > from
> > > > > "
> > > > >                         + "pid=" + Binder.getCallingPid() + ", "
> > > > >                         + "uid=" + Binder.getCallingUid());
> > > > >                 return;
> > > > >             }
>
> > > > >             // Save the android ID so the new system can get it
> > erased.
> > > > >             try {
> > > > >                 RecoverySystem.rebootAndWipe();
> > > > >             } catch (IOException e) {
> > > > >                 Log.e(TAG, "Reboot for masterClear() failed", e);
> > > > >             }
> > > > >         }
>
> > > > > I'll be sure that gets added to the fallback service.
>
> > > > > On Thu, Feb 5, 2009 at 3:49 PM, Dave <[email protected]> wrote:
>
> > > > > > The Settings application (masterClear.java) is doing nothing other
> > > > > > than calling the checkin service's masterClear method.  How does
> > > > > > masterClear get to the point of deleting the /data partition if
> > > > > > FallbackCheckinService's implementation of masterClear() is empty?
>
> > > > > > On Feb 5, 5:35 pm, Dianne Hackborn <[email protected]> wrote:
> > > > > > > This has nothing to do with hardware, it's for doing device
> > checkins
> > > > with
> > > > > > a
> > > > > > > remote server.  This is used on the G1 to check in with Google
> > > > servers to
> > > > > > > check for updates etc.  If you don't want such a feature, you
> > don't
> > > > need
> > > > > > an
> > > > > > > implementation.
>
> > > > > > > On Thu, Feb 5, 2009 at 3:03 PM, Dave <[email protected]>
> > wrote:
>
> > > > > > > > Looking at the implementation of SystemServer and
> > > > > > > > FallbackCheckinService, it appears that the implementation of
> > > > > > > > masterClear() and each of the other methods in this service is
> > just
> > > > a
> > > > > > > > no-op.
>
> > > > > > > > Is each OEM expected to implement a custom version of this to
> > > > > > > > integrate with their specific hardware (aka a HAL interface)
>
> > > > > > > --
> > > > > > > Dianne Hackborn
> > > > > > > Android framework engineer
> > > > > > > [email protected]
>
> > > > > > > Note: please don't send private questions to me, as I don't have
> > time
> > > > to
> > > > > > > provide private support.  All such questions should be posted on
> > > > public
> > > > > > > forums, where I and others can see and answer them.
>
> > > > > --
> > > > > Dianne Hackborn
> > > > > Android framework engineer
> > > > > [email protected]
>
> > > > > Note: please don't send private questions to me, as I don't have time
> > to
> > > > > provide private support.  All such questions should be posted on
> > public
> > > > > forums, where I and others can see and answer them.- Hide quoted text
> > -
>
> > > > > - Show quoted text -
>
> > > --
> > > Dianne Hackborn
> > > Android framework engineer
> > > [email protected]
>
> > > Note: please don't send private questions to me, as I don't have time to
> > > provide private support.  All such questions should be posted on public
> > > forums, where I and others can see and answer them.- Hide quoted text -
>
> > > - Show quoted text -
>
> --
> Dianne Hackborn
> Android framework engineer
> [email protected]
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support.  All such questions should be posted on public
> forums, where I and others can see and answer them.- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to