CN114154180A - 数据共享方法和终端设备 - Google Patents

数据共享方法和终端设备 Download PDF

Info

Publication number
CN114154180A
CN114154180A CN202111419833.8A CN202111419833A CN114154180A CN 114154180 A CN114154180 A CN 114154180A CN 202111419833 A CN202111419833 A CN 202111419833A CN 114154180 A CN114154180 A CN 114154180A
Authority
CN
China
Prior art keywords
user
application
external storage
users
common service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111419833.8A
Other languages
English (en)
Inventor
张亚芹
王旭光
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hisense Mobile Communications Technology Co Ltd
Original Assignee
Hisense Mobile Communications Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hisense Mobile Communications Technology Co Ltd filed Critical Hisense Mobile Communications Technology Co Ltd
Priority to CN202111419833.8A priority Critical patent/CN114154180A/zh
Publication of CN114154180A publication Critical patent/CN114154180A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/604Tools and structures for managing or administering access control systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Automation & Control Theory (AREA)
  • Data Mining & Analysis (AREA)
  • Stored Programmes (AREA)

Abstract

本申请涉及终端技术领域,公开了一种数据共享方法和终端设备,用以解决现有技术中还不能实现基于用户空间文件系统Fuse的用户数据共享的问题。该方法包括:在终端设备上创建多个用户;将所述终端设备的公共服务commonservice组件与所述多个用户绑定;利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理。该方法中提出了公共服务commonservice概念,利用commonservice绑定(binder)到多个用户的存储管理服务(storageManagerservice),并在不同用户之间进行跨用户的存储权限管理,实现Fuse系统中的数据共享。

Description

数据共享方法和终端设备
技术领域
本申请涉及终端技术领域,尤其涉及一种数据共享方法和终端设备。
背景技术
同一终端设备可支持不同用户使用。为了保护用户数据,安卓提出了Fuse(Filesystem in Userspace,用户空间文件系统)。在Fuse中,每个用户的数据放在内核层,由Fuse来进行管理和维护。
例如,Android(安卓)手机设备上创建多个用户,包括用户1和用户2,但是每个用户只能访问自己的数据,目前还不能实现基于Fuse文件系统的用户数据共享。
发明内容
本申请的目的是提供一种数据共享方法和终端设备,用以解决现有技术中还不能实现基于Fuse文件系统的用户数据共享的问题。
第一方面,本申请提供一种数据共享方法,所述方法包括:
在终端设备上创建多个用户;
将所述终端设备的公共服务commonservice组件与所述多个用户绑定;
利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理。
在一种可能的实施方式中,将所述终端设备的公共服务commonservice组件与所述多个用户绑定,包括:
为所述多个用户中的每个用户创建存储管理服务storageManagerservice组件,每个用户的所述storageManagerservice组件用于管理所述用户的存储权限;
将所述commonservice组件绑定至所述多个用户中每个用户的storageManagerservice组件。
在一种可能的实施方式中,利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理,包括:
调用所述commonservice组件,对来自第一应用的外部存储权限请求进行解析,获取所述第一应用对外部存储权限的申请信息,所述第一应用属于所述多个用户中的第一用户,所述申请信息用于指示所述第一用户和所述多个用户中待访问的第二用户;
调用所述commonservice组件,根据所述申请信息在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理;
调用所述commonservice组件,向所述第二用户发送外部存储权限授权通知,所述外部存储权限授权通知用于指示将所述第二用户的用户空间文件系统Fuse的访问权限授权给所述第一应用。
在一种可能的实施方式中,所述第一应用对外部存储权限的申请信息至少包括所述第一用户的标识和所述第二用户的标识。
在一种可能的实施方式中,调用所述commonservice组件,根据所述申请信息在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理,包括:
调用所述commonservice组件,根据所述第一用户的标识和所述第二用户的标识确定满足预设的跨用户授权条件;
调用所述commonservice组件,在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理。
在一种可能的实施方式中,所述跨用户授权条件包括:所述第一用户的标识和所述第二用户的标识不同。
在一种可能的实施方式中,调用所述commonservice组件,向所述第二用户发送外部存储权限授权通知,包括:
调用所述commonservice组件,经由所述第二用户的storageManagerservice组件向所述第二用户的媒体提供者组件MediaProvider发送所述外部存储权限授权通知。
在一种可能的实施方式中,所述方法还包括:
显示权限设置界面;
基于在所述权限设置界面中针对所述第一应用的用户操作,确定所述第一应用的外部存储权限请求。
第二方面,本申请实施例提供一种终端设备,包括:
处理器和存储器;
所述存储器,用于存储所述处理器的可执行指令;
所述处理器被配置为执行所述指令以实现如上述第一方面中任一项所述的数据共享方法。
第三方面,本申请实施例提供一种计算机可读存储介质,包括:当所述计算机可读存储介质中的指令由所述终端设备执行时,使得所述终端设备能够执行如上述第一方面中任一项所述的数据共享方法。
第四方面,本申请提供一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时实现如上述第一方面中任一项所述的数据共享方法。
本申请的实施例提供的技术方案至少带来以下有益效果:
本申请实施例中通过在终端设备上创建多个用户;将所述终端设备的公共服务commonservice组件与所述多个用户绑定;利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理,由此可以实现多个用户对Fuse系统中的数据共享,以及多用户系统中指定用户间的数据共享。
本申请的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单地介绍,显而易见地,下面所介绍的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的各个用户独立访问数据的流程示意图;
图2为本申请实施例提供的安卓系统的存储目录结构;
图3为本申请实施例提供的运行时视图挂载点的示意图;
图4a和图4b为本申请实施例提供的不同用户的应用路径权限的示意图;
图5为本申请实施例提供的一种终端设备的结构示意图;
图6为本申请实施例提供的终端设备的软件结构框图;
图7为本申请实施例提供的应用场景示意图;
图8为本申请实施例提供的一种数据共享方法的流程示意图;
图9为本申请实施例提供的多用户共享数据的流程示意图;
图10为本申请实施例提供的权限设置页面的示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。其中,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
并且,在本申请实施例的描述中,除非另有说明,″/″表示或的意思,例如,A/B可以表示A或B;文本中的″和/或″仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况,另外,在本申请实施例的描述中,″多个″是指两个或多于两个。
以下,术语″第一″、″第二″仅用于描述目的,而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有″第一″、″第二″、的特征可以明示或者隐含地包括一个或者更多个该特征,在本申请实施例的描述中,除非另有说明,″多个″的含义是两个或两个以上。
以下,对本申请实施例中的部分用语进行解释说明,以便于本领域技术人员理解。
1)多用户系统:可以支持多个用户使用系统。通常,第一个在系统中注册的用户为系统管理员用户。不同用户的设置各不相同,并且不同用户安装的应用及应用数据也不相同。但是系统中和硬件相关的设置则是共用的,例如网络设置等。
2)Android外部存储:应用程序可以使用的文件存储区域包括两个:内部存储空间、外部存储空间。这两个名称是在Android早期确定的,那时候大部分设备都提供内置的非易失性存储(内部存储空间)以及可移动的存储媒介,例如Micro SD卡(外部存储空间)。现在,很多设备将永久性存储空间划分为单独的″内部″和″外部″分区。因此,即使没有可移动存储媒介,这两种存储空间也始终存在,并且无论外部存储空间是否可移动。
3)MediaProvider(媒体提供者组件):安卓(Android)系统下统一扫描、控制系统所有目录下媒体文件的一个系统服务。这里的媒体包括图片、视频、音乐等等。在多用户系统下,每个用户可以具有各自的MediaProvider。
4)Fuse(用户空间文件系统,Filesystem inUserspace):是Linux(类Uni×操作系统,GNU/Linu×)中用于挂载某些网络空间,如SSH(安全外壳协议,Secure Shell),到本地文件系统的模块,在SourceForge(源码炉)上可以找到相关内容。具有简单的API(应用程序接口,Application Programming Interface)库,可以被非特权用户访问,并可以安全的实施,具有稳定性。
现有技术中,同一终端设备可支持不同用户使用。为了保护用户数据,安卓提出了Fuse(Filesystem in Userspace,用户空间文件系统)。在Fuse中,每个用户的数据放在内核层,由Fuse来进行管理和维护。
如图1所示,为各个用户独立访问数据的流程示意图。Android设备上可以创建多个用户,包括用户0和用户10(0和10表示用户标识(Identity document,ID)),但是每个用户只能访问自己的数据,目前还不能实现基于Fuse文件系统的用户数据共享。
具体如图1所示:Android设备包括用户0和用户10,用户0最早创建,则用户0可以为管理员。用户0的应用数据存放在data/user/0中,用户10的应用数据存放在data/user/10/中。Fuse系统中也同样存在两个目标,其中storage/emulated/0对应用户0的data/user/0,storage/emulated/10对应用户10的data/user/10/相应的,Fuse系统下的存储目录结构如图2所示。
用户0对应三个组件分别为MediaProvider0、connection0和Fuse进程0,用户10对应三个主要组件分别为MediaProvider10、connection10和Fuse进程10。用户0通过自己的MediaProvider0、connection0和Fuse进程0实现对用户0数据的操作,同理,用户10通过MediaProvider10、connection10和Fuse进程10实现对用户10的数据访问,隔离了不同用户。基于此,在具有多用户的安卓设备上,每个用户都可以安装自己的独立应用程序,应用程序的对于外部存储的访问也是基于用户隔离的。
在目前的Adnroid系统中,外部存储空间实际上通过Linu× Mount(挂载)和BindMount(绑定挂载)对内部数据目录″/data/media″的重新挂载,通过给应用挂载合适的运行时视图,实现对外部存储的访问控制。
为了能够达到动态权限管理的目的,Android使用了mount namespace(挂载命名空间),在Zygote fork应用进程的时候会通过unshare(取消分享)系统调用为应用进程创建一个mount namespace,在应用自己的mount namespace中根据传递给Zygote的参数决定将/storage绑定挂载到运行时视图挂载点上,如图3所示。
绑定(Bind)到不同的视图挂载点上的应用拥有不同的权限。如图4a和图4b所示,为应用的路径权限说明。其中,如图4a所示,以/mnt/androidwriteable/0/emulated为例,该目录下都是u0权限,即用户0(user0)下的应用可以访问。如图4b所示,以/mnt/androidwriteable/10/emulated为例此目录下都是u10权限,即用户10(user10)下的应用可以访问。其中,u0指的是user0,u10指的是user10,程序中用uid来标识。a175是进程id,用pid来标识,a175是mediaprovider进程。u0_175是user0下面的MediaProvider进程,u10_a175指的是user10下面的MediaProvider进程。
在应用权限发生变化时,应用所属用户的对应权限管理服务组件(PermissionManagerservice)根据应用的权限变动,会调用到挂载进程(vold)对应用进程空间的/storage重新挂载并通知MediaProvider更新权限。在App启动的时候,Zygote会根据应用权限的授予情况,在进程fork的时候为应用进程创建挂载命名空间(mountnamespace),将应用程序所在的mount namespace中绑定挂载(bind mount)到不同运行时视图挂载点上。在应用程序权限发生变化时(获得权限),权限管理服务组件会通知void重新mount不同的运行时视图挂载点,然后通知MediaProvider volume change的变化,触发权限更新。但该权限更新仅是对应用所属的用户下的权限更新,仍为基于用户隔离的。
但是一些特殊场景,例如分享图片的场景,需要跨用户访问外部存储。
例如,以应用基于多用户的应用多开场景。主用户安装的应用A,并且双开了应用A,将双开后的应用成为A1。设备的使用者,开启主应用A时,A应用要求申请外部存储的读写权限,此读写权限申请后,仅能读取A应用所在的主用户的外部存储空间。分身用户下A1申请外部存储的读写权限后,仅能访问分身用户的外部存储空间。Fuse将难以满足该场景中应用A对分身用户A1的外部存储空间的访问需求,故此,如何在Fuse系统中实现数据共享有待解决。
有鉴于此,本申请提出了一种数据共享方法,该方法中提出了公共服务(commonservice)概念,利用commonservice绑定(binder)到多个用户的存储管理器服务(storageManagerservice),在不同用户之间进行跨用户的存储权限管理,实现Fuse系统中的数据共享。
下面首先对本申请提供的终端设备进行说明。
图5示出了一种终端设备500的结构示意图。应该理解的是,图5所示终端设备500仅是一个范例,并且终端设备500可以具有比图5中所示的更多的或者更少的部件,可以组合两个或多个的部件,或者可以具有不同的部件配置。图5中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
图5中示例性示出了根据示例性实施例中终端设备500的硬件配置框图。如图5所示,终端设备500包括:射频(radio frequency,RF)电路510、存储器520、显示单元530、摄像头540、传感器550、音频电路560、无线保真(Wireless Fidelity,Wi-Fi)模块570、处理器580、蓝牙模块581、以及电源590等部件。
RF电路510可用于在收发信息或通话过程中信号的接收和发送,可以接收基站的下行数据后交给处理器580处理;可以将上行数据发送给基站。通常,RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等器件。
存储器520可用于存储软件程序及数据。处理器580通过运行存储在存储器520的软件程序或数据,从而执行终端设备500的各种功能以及数据处理。存储器520可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。存储器520存储有使得终端设备500能运行的操作系统。本申请中存储器520可以存储操作系统及各种应用程序,还可以存储执行本申请实施例所述方法的程序代码。
显示单元530可用于接收输入的数字或字符信息,产生与终端设备500的用户设置以及功能控制有关的信号输入,具体地,显示单元530可以包括设置在终端设备500正面的触摸屏531,可收集用户在其上或附近的触摸操作,例如点击按钮,拖动滚动框等。
显示单元530还可用于显示由用户输入的信息或提供给用户的信息以及终端设备500的各种菜单的图形用户界面(graphical userinterface,GUI)。具体地,显示单元530可以包括设置在终端设备500正面的显示屏532。其中,显示屏532可以采用液晶显示器、发光二极管等形式来配置。
其中,触摸屏531可以覆盖在显示屏532之上,也可以将触摸屏531与显示屏532集成而实现终端设备500的输入和输出功能,集成后可以简称触摸显示屏。本申请中显示单元530可以显示应用程序以及对应的操作步骤。
摄像头540可用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device,CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor,CMOS)光电晶体管。感光元件把光信号转换成电信号,之后将电信号传递给处理器580转换成数字图像信号。
终端设备500还可以包括至少一种传感器550,比如加速度传感器551、距离传感器552、指纹传感器553、温度传感器554。终端设备500还可配置有陀螺仪、气压计、湿度计、温度计、红外线传感器、光传感器、运动传感器等其他传感器。
音频电路560、扬声器561、麦克风562可提供用户与终端设备500之间的音频接口。音频电路560可将接收到的音频数据转换后的电信号,传输到扬声器561,由扬声器561转换为声音信号输出。终端设备500还可配置音量按钮,用于调节声音信号的音量。另一方面,麦克风562将收集的声音信号转换为电信号,由音频电路560接收后转换为音频数据,再将音频数据输出至RF电路510以发送给比如另一终端设备,或者将音频数据输出至存储器520以便进一步处理。
Wi-Fi属于短距离无线传输技术,终端设备500可以通过Wi-Fi模块570帮助用户收发电子邮件、浏览网页和访问流媒体等,它为用户提供了无线的宽带互联网访问。
处理器580是终端设备500的控制中心,利用各种接口和线路连接整个终端设备的各个部分,通过运行或执行存储在存储器520内的软件程序,以及调用存储在存储器520内的数据,执行终端设备500的各种功能和处理数据。在一些实施例中,处理器580可包括一个或多个处理单元;处理器580还可以集成应用处理器和基带处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,基带处理器主要处理无线通信。可以理解的是,上述基带处理器也可以不集成到处理器580中。本申请中处理器580可以运行操作系统、应用程序、用户界面显示及触控响应,以及本申请实施例所述的数据共享方法。另外,处理器580与显示单元530耦接。
蓝牙模块581,用于通过蓝牙协议来与其他具有蓝牙模块的蓝牙设备进行信息交互。例如,终端设备500可以通过蓝牙模块581与同样具备蓝牙模块的可穿戴电子设备(例如智能手表)建立蓝牙连接,从而进行数据交互。
终端设备500还包括给各个部件供电的电源590(比如电池)。电源可以通过电源管理系统与处理器580逻辑相连,从而通过电源管理系统实现管理充电、放电以及功耗等功能。终端设备500还可配置有电源按钮,用于终端设备的开机和关机,以及锁屏等功能。
图6是本申请实施例的终端设备500的软件结构框图。
分层架构将软件分成若干个层,每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中,可将Android系统分为四层,从上至下分别为应用程序层,应用程序框架层,安卓运行时(Android runtime)和系统库,以及内核层。
应用程序层可以包括一系列应用程序包。
如图6所示,应用程序包可以包括相机,图库,日历,通话,地图,导航,WLAN,蓝牙,音乐,视频,短信息等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface,API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图6所示,应用程序框架层可以包括窗口管理器,内容提供器,视图系统,电话管理器,资源管理器,通知管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小,判断是否有状态栏,锁定屏幕,截取屏幕等。
内容提供器用来存放和获取数据,并使这些数据可以被应用程序访问。所述数据可以包括视频,图像,音频,拨打和接听的电话,浏览历史和书签,电话簿、短信息等。
视图系统包括可视控件,例如显示文字的控件,显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如,包括短信息通知图标的显示界面,可以包括显示文字的视图以及显示图片的视图。
电话管理器用于提供终端设备500的通信功能。例如通话状态的管理(包括接通,挂断等)。
资源管理器为应用程序提供各种资源,比如本地化字符串,图标,图片,布局文件,视频文件等。
通知管理器使应用程序可以在状态栏中显示通知信息(例如短信息的消息摘要,消息内容),可以用于传达告知类型的消息,可以短暂停留后自动消失,无需用户交互。比如通知管理器被用于告知下载完成,消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知,例如后台运行的应用程序的通知,还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息,发出提示音,终端设备振动,指示灯闪烁等。
Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。
核心库包含两部分:一部分是java语言需要调用的功能函数,另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理,堆栈管理,线程管理,安全和异常的管理,以及垃圾回收等功能。
系统库可以包括多个功能模块。例如:表面管理器(surface manager),媒体库(Media Libraries),三维图形处理库(例如:OpenGL ES),2D图形引擎(例如:SGL)等。
表面管理器用于对显示子系统进行管理,并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频,视频格式回放和录制,以及静态图像文件等。媒体库可以支持多种音视频编码格式,例如:MPEG4,H.264,MP3,AAC,AMR,JPG,PNG等。
三维图形处理库用于实现三维图形绘图,图像渲染,合成,和图层处理等。
2D(一种动画方式)图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含显示驱动,摄像头驱动,音频驱动,传感器驱动。
本申请实施例中的终端设备500可以为包括但不限于手机、移动终端、桌面计算机、移动电脑、平板电脑、家用体征数据采集设备(如血压仪)、电视等电子设备。
下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍,需要说明的是,以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施时,可以根据实际需要灵活地应用本申请实施例提供的技术方案。
如图7所示示出了本申请实施例提供的应用场景示意图。该应用场景图包括用户A、应用701、终端设备702、应用703、用户B。其中:
用户A使用应用701获取数据并将数据存储在终端设备702中用户A的外部存储中,用户B可以通过在终端设备701,使用应用703访问用户A的外部存储中存储的数据。例如,用户A在终端设备702中安装了应用701,并用应用701拍摄了一张照片,存储在用户A的文件目录下,而用户B安装在终端设备702中的应用703可以查看这一张照片。
当然,本申请实施例提供的方法并不限于图7所示的应用场景,还可以用于其它可能的应用场景,本申请实施例并不进行限制。对于图7所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述,在此先不过多赘述。
为进一步说明本申请实施例提供的技术方案,下面结合附图以及具体实施方式对此进行详细的说明。
图8示出了本申请实施例提供数据共享方法的流程示意图,如图8所示,该方法可以包括以下步骤:
S801:在终端设备上创建多个用户。
本步骤中,以在终端设备上创建的多个用户为前文述及的用户0和用户10为例,如图1所示,创建了用户0和用户10,用户0的应用数据可以存放在data/user/O目录下,用户10的应用数据可以存放在data/user/10/目录中。Fuse系统中也同样存在两个目录,其中storage/emulated/O对应用户0的data/user/0,storage/emulated/10对应用户10的data/user/10/。用户0和用户10可以拥有自己的MediaProvider,各自的MediaProvider可以通过connection的方式和Fuse进程连接,通过Fuse对storage/emulated/O和storage/emulated/10进行管理。
S802:将所述终端设备的公共服务commonservice组件与所述多个用户绑定。
本步骤中,如图9所示,可以为所述多个用户中的每个用户创建存储管理服务组件(storageManagerservice),每个用户的所述storageManagerservice用于管理所述用户的存储权限。进一步地,终端设备将所述commonservice组件绑定(binder)至所述多个用户中每个用户的storageManagerservice组件。进而,在终端设备的多个用户下的应用程序申请对终端设备的外部存储空间的访问权限时,可以通过调用该commonservice组件完成相应应用的权限关管理。
S803:利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理。
具体实施时,该S803可以包括以下步骤:
(1)第一应用发起外部存储权限请求。其中,第一应用可以属于终端设备的多个用户中的第一用户,也称为源用户。
如图9所示,以用户0表示该第一用户,用户10可以表示该第一应用申请访问的第二用户。第一用户下的第一应用可以在安装时或者设置外部存储权限时触发该外部存储权限请求,表示为:android.permission.WRITE_EXTERNAL_STORAGE。
可以理解的是,第一应用发起外部存储权限请求时,也可以申请访问相同用户下的外部存储空间,即第一用户与第二用户相同。本申请实施例主要用于解决跨用户授予外部存储权限的问题,以第二用户表示第一应用申请访问的目标用户,并不限定该目标用户与第一应用所属的第一用户相同还是不同。
(2)响应于该外部存储权限请求,终端设备可以调用commonservice组件对该外部存储权限请求进行解析,在用户0的PermissionManagerservice的授予运行时权限接口grantRuntimePermission()中,获取第一应用对外部存储权限的申请信息,该申请信息可以用于指示第一应用所属的第一用户(也称为源用户)以及所述多个用户中该第一应用申请访问的第二用户(也称为目标用户)。
示例地,该申请信息可以包括但不限于:第一应用的包名(packageName);第一应用申请的权限名称(permissionName);第一用户的标识,也称为源用户标识,可以表示为CallingUserID,该CallingUserID可以从callingUid中获取;所述多个用户中待访问的第二用户的标识,也称为目标用户标识,可以表示为userid。
(3)终端设备可以调用commonservice组件,根据所述申请信息确定是否在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理。
本申请实施例中,可以预设跨用户授权条件,该跨用户授权条件例如可以为:应用的源用户标识与应用申请访问的目标用户标识不同。终端设备调用commonservice组件进行判断决策时,可以通过比对触发该外部存储权限请求的第一应用的申请信息指示的第一用户的标识和第二用户的标识是否不同,判定是否满足该跨用户授权条件。若满足,则可以调用所述commonservice组件,根据所述申请信息在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理。若不满足,则无需执行跨用户权限的授予流程。
(4)终端设备调用commonservice组件,根据所述申请信息在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理。
如图9所示,根据申请信息以及(3)中的判决结果,在确定需要进行跨用户外部存储授权处理时,可以触发用户0的storagemanagerservice的外部存储策略变更接口(onExternalStoragePolicyChanged)的重新安装源用户外部存储(remountUidExternalStorage(uid,mountMode)),以通知vold进程重新挂载运行时视图挂载点。
(5)终端设备调用commonservice组件,向所述第二用户(例如用户10)发送外部存储权限授权通知,所述外部存储权限授权通知用于指示将所述第二用户的用户空间文件系统Fuse的访问权限授予所述第一应用。
如图9所示,终端设备调用所述commonservice组件,经由所述第二用户的storageManagerservice组件向第二用户的媒体提供者组件MediaProvider发送所述外部存储权限授权通知,具体可以由storagemanagerservice的存储用户连接(StorageUserConnection)通知给user10的MediaProvider,这样第二用户的MediaProvider就更新了该第一应用的存储权限,比如将访问/mnt/androidwriteable/10/emulated的权限授予用户0,用户0的存储目录变更为:Storage/emulated/0 /mnt/androidwriteable/0/emulated。
由此,通过上述方法,终端设备通过利用所述commonservice组件对来自第一应用的外部存储权限请求进行解析、并进行跨用户外部存储授权处理流程,实现多个用户对Fuse系统中的数据共享,以及多用户系统中指定用户间的数据共享。
在一种可能的实施方式中,第一应用发起外部存储权限请求,可实施为:首先显示权限设置界面给用户;然后,基于在所述权限设置界面中针对所述第一应用的用户操作,确定所述第一应用的外部存储权限请求。
如图10所示,在图10的权限设置界面中,用户可以根据提示确定所述第一应用的外部存储权限请求。其中,用户可以通过触屏或者按键的方式选择第一应用的访问权限的配置选项,从而触发该外部存储权限请求。
在一种可能的实施方式中,所述第一应用对所述第二用户的访问权限可以包括所述第二用户的即时通信工具的图片库或所述第二用户的图片应用的图片库。这样,第一应用只能访问第二用户的一些图片库中的信息,对其他信息不能访问。能够实现不同用户间共享图片的需求,还能够保护用户的其他隐私信息。
在一种可能的实施方式中,若第一应用结束访问第二用户的数据,则还可以发出撤销请求,终端设备还可以响应于第一应用的撤销请求,取消对第一应用的授权。由此,第一应用和第二用户不再共享数据。
基于前文的描述,本申请实施例通过在终端设备上创建多个用户;将所述终端设备的公共服务commonservice组件与所述多个用户绑定;利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理。该方法中提出了公共服务commonservice概念,利用commonservice绑定(binder)到多个用户的存储管理服务(storageManagerservice),并在不同用户之间进行跨用户的存储权限管理,实现Fuse系统中的数据共享。
本申请提供的实施例之间的相似部分相互参见即可,以上提供的具体实施方式只是本申请总的构思下的几个示例,并不构成本申请保护范围的限定。对于本领域的技术人员而言,在不付出创造性劳动的前提下依据本申请方案所扩展出的任何其他实施方式都属于本申请的保护范围。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种数据共享方法,其特征在于,所述方法包括:
在终端设备上创建多个用户;
将所述终端设备的公共服务commonservice组件与所述多个用户绑定;
利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理。
2.根据权利要求1所述的方法,其特征在于,将所述终端设备的公共服务commonservice组件与所述多个用户绑定,包括:
为所述多个用户中的每个用户创建存储管理服务storageManagerservice组件,每个用户的所述storageManagerservice组件用于管理所述用户的存储权限;
将所述commonservice组件绑定至所述多个用户中每个用户的storageManagerservice组件。
3.根据权利要求1或2所述的方法,其特征在于,利用所述commonservice组件,在所述多个用户之间进行跨用户外部存储授权处理,包括:
调用所述commonservice组件,对来自第一应用的外部存储权限请求进行解析,获取所述第一应用对外部存储权限的申请信息,所述第一应用属于所述多个用户中的第一用户,所述申请信息用于指示所述第一用户以及所述多个用户中待访问的第二用户;
调用所述commonservice组件,根据所述申请信息在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理;
调用所述commonservice组件,向所述第二用户发送外部存储权限授权通知,所述外部存储权限授权通知用于指示将所述第二用户的用户空间文件系统Fuse的访问权限授予所述第一应用。
4.根据权利要求3所述的方法,其特征在于,所述第一应用对外部存储权限的申请信息至少包括所述第一用户的标识和所述第二用户的标识。
5.根据权利要求4所述的方法,其特征在于,调用所述commonservice组件,根据所述申请信息在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理,包括:
调用所述commonservice组件,根据所述第一用户的标识和所述第二用户的标识确定满足预设的跨用户授权条件;
调用所述commonservice组件,在所述第一用户和所述第二用户之间进行跨用户外部存储授权处理。
6.根据权利要求5所述的方法,其特征在于,所述跨用户授权条件包括:所述第一用户的标识和所述第二用户的标识不同。
7.根据权利要求3所述的方法,其特征在于,调用所述commonservice组件,向所述第二用户发送外部存储权限授权通知,包括:
调用所述commonservice组件,经由所述第二用户的storageManagerservice组件向所述第二用户的媒体提供者组件MediaProvider发送所述外部存储权限授权通知。
8.根据权利要求3所述的方法,其特征在于,所述方法还包括:
显示权限设置界面;
基于在所述权限设置界面中针对所述第一应用的用户操作,确定所述第一应用的外部存储权限请求。
9.一种终端设备,其特征在于,包括:
处理器和存储器;
所述存储器,用于存储所述处理器的可执行指令;
所述处理器被配置为执行所述指令以实现如权利要求1-8中任一项所述的数据共享方法。
10.一种计算机可读存储介质,其特征在于,包括:
当所述计算机可读存储介质中的指令由所述终端设备执行时,使得所述终端设备能够执行如权利要求1-8中任一项所述的数据共享方法。
CN202111419833.8A 2021-11-26 2021-11-26 数据共享方法和终端设备 Pending CN114154180A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111419833.8A CN114154180A (zh) 2021-11-26 2021-11-26 数据共享方法和终端设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111419833.8A CN114154180A (zh) 2021-11-26 2021-11-26 数据共享方法和终端设备

Publications (1)

Publication Number Publication Date
CN114154180A true CN114154180A (zh) 2022-03-08

Family

ID=80458226

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111419833.8A Pending CN114154180A (zh) 2021-11-26 2021-11-26 数据共享方法和终端设备

Country Status (1)

Country Link
CN (1) CN114154180A (zh)

Similar Documents

Publication Publication Date Title
CN113032766B (zh) 应用权限管理的方法和装置
EP4095723B1 (en) Permission reuse method, permission reuse-based resource access method, and related device
WO2019015491A1 (zh) 应用程序的分身方法、装置、设备和介质
CN113835569A (zh) 终端设备、应用内部功能的快捷启动方法和存储介质
CN113835928A (zh) 应用的备份和恢复方法、设备、存储介质和程序产品
CN111158735B (zh) 一种热补丁文件处理方法及通信终端
CN112825072B (zh) 通信终端以及数据共享方法
CN114675786A (zh) 一种大容量存储挂载方法、装置、终端及介质
CN114595203A (zh) 基于双系统的文件同步方法、终端设备及存储介质
CN113642010B (zh) 一种获取扩展存储设备数据的方法及移动终端
CN114154180A (zh) 数据共享方法和终端设备
CN113496039B (zh) 一种权限管理方法及终端
CN111600862B (zh) 一种用户账户管理方法及设备
CN113938890B (zh) 数据共享方法和终端设备
CN111159734A (zh) 通信终端及多应用数据互访处理方法
CN114138343A (zh) 一种终端及终端启动方法
CN113836540B (zh) 管理应用权限的方法、设备、存储介质和程序产品
CN115981576B (zh) 共享数据的方法、电子设备及存储介质
CN115017473B (zh) 授权方法及电子设备
CN113835889A (zh) 获取输入事件的方法和相关装置
CN114911394B (zh) 一种终端设备以及单手操作方法
CN114356352A (zh) 多用户下应用数据的管理方法和终端设备
CN112764832A (zh) 一种应用程序安装、卸载方法及通信终端
CN113836540A (zh) 管理应用权限的方法、设备、存储介质和程序产品
CN117857646A (zh) 数据网络共享方法、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination