Project

General

Profile

RestoreApplicationInternalData » History » Version 37

Denis 'GNUtoo' Carikli, 11/10/2020 07:56 PM
backup: add tab2

1 1 Denis 'GNUtoo' Carikli
h1. RestoreApplicationInternalData
2
3
{{toc}}
4
5
h2. /!\ Warning: Draft
6
7
This article is in draft form and is being written:
8
* Everybody is welcome to contribute
9
* Some things might not be accurate yet, so beware before using the information contained in it.
10 2 Denis 'GNUtoo' Carikli
11 26 Denis 'GNUtoo' Carikli
h2. TODO
12
13 30 Denis 'GNUtoo' Carikli
* Explain how to handle a corrupted /data/system/packages.xml and /data/system/appops.xml, for instance by ussing a block level backup of your data partition.
14 26 Denis 'GNUtoo' Carikli
15 15 Denis 'GNUtoo' Carikli
h2. Rationale
16 2 Denis 'GNUtoo' Carikli
17
In some case, it is useful to be able to restore internal applications data:
18 9 Denis 'GNUtoo' Carikli
19
For instance you might need to move the data of an application from a device to another if you want to switch device.
20
21 29 Denis 'GNUtoo' Carikli
Another use case is if /data/system/packages.xml and/or /data/system/appops.xml get corrupted, applications can loose access to their data. This can make the launcher and other applications crash. 
22 9 Denis 'GNUtoo' Carikli
23
So while it is possible to recover from that by wiping the data partition in the recovery, sometimes it's very impractical to do that because you might have important data like silence encryption keys and established sessions that you don't want to loose.
24 3 Denis 'GNUtoo' Carikli
25 16 Denis 'GNUtoo' Carikli
h2. Goals
26 1 Denis 'GNUtoo' Carikli
27 13 Denis 'GNUtoo' Carikli
This howto will explain how to move silence data from a device to another.
28 1 Denis 'GNUtoo' Carikli
29
For instance you could want to move from a Galaxy SIII (GT-I9300) to a Galaxy SII (GT-I9100) or vice versa, and you might not want to recreate keys, sessions, etc when moving device.
30
31 16 Denis 'GNUtoo' Carikli
This could also be adapted to restore application data from a block device level backup of the internal eMMC or the internal data partition.
32
33 14 Denis 'GNUtoo' Carikli
h2. Silence
34 1 Denis 'GNUtoo' Carikli
35 14 Denis 'GNUtoo' Carikli
Silence has been chosen as an example for this tutorial because:
36
* It's an application commonly used
37
* Loosing its data (key, sessions) can be painful
38
39 1 Denis 'GNUtoo' Carikli
Silence stores its data in the internal application storage. As far as I know it's not supposed to store any data on the microSD or user storage beside potential backups.
40
41 14 Denis 'GNUtoo' Carikli
It might be interesting to make additional tutorial for other cases. For instance for:
42
* Applications that also require data to be on the microSD or user storage.
43
* System applications that have their data in a database.
44 1 Denis 'GNUtoo' Carikli
45
h2. Requirements 
46
47
This howto assumes that the data partition is unencrypted. If you know how to open encrypted data partition in the recovery, or in a GNU/Linux distribution, it would be great to either modify this tutorial to add information on how to do it, or contact us on the mailing list or through the bugreporting system about it.
48
49 27 Denis 'GNUtoo' Carikli
h2. Setup ADB
50
51
Follow the instructions for [[ADB|setting up ADB on your computer]] so that you can access a root shell on your device.
52
53
*NOTE*: when prompted on your Replicant device, make sure that you check the box that says *Always allow from this computer* when you grant your computer USB debugging permissions. Otherwise, you will be unable to obtain root shell access on your Replicant device when you reboot it into the recovery OS to actually perform the backup.
54
55
*NOTE*: for security reasons, you may want to [[ADB#Revoking-all-computers-USB-debugging-permissions|revoke these non-expiring permissions]] once the backup is complete.
56
57 1 Denis 'GNUtoo' Carikli
h2. Backuping Silence's data from the old device
58
59 34 Denis 'GNUtoo' Carikli
h3. Mounting the data partition
60
61 19 Denis 'GNUtoo' Carikli
To correctly backup the application data, you need to make sure that the application isn't writing to its data while you are doing the backup and that the data is consistent.
62
63
To make sure of that the easiest way to do that is to go in the recovery: this way the application will not be started automatically and the data is consistent. You will also need a root shell there, so make sure to setup that beforehand.
64
65
If everything is setup correctly, running @adb shell@ from your computer should result in a shell that now looks like this:
66 16 Denis 'GNUtoo' Carikli
<pre>
67 19 Denis 'GNUtoo' Carikli
root@m0:/ #
68 1 Denis 'GNUtoo' Carikli
</pre>
69
70 19 Denis 'GNUtoo' Carikli
Once that you have a shell in the recovery, you need to mount the data partition in /data from within that shell.
71
72 34 Denis 'GNUtoo' Carikli
h4. Galaxy SII (GT-I9100)
73
74 33 Denis 'GNUtoo' Carikli
For the Galaxy SII (GT-I9100), this can be done from your computer with this command:
75
<pre>
76
mount /dev/block/platform/*/by-name/DATAFS /data
77
</pre>
78
79 34 Denis 'GNUtoo' Carikli
h4. Galaxy SIII (GT-I9300)
80
81 19 Denis 'GNUtoo' Carikli
For the Galaxy SIII (GT-I9300), this can be done from your computer with this command:
82 16 Denis 'GNUtoo' Carikli
<pre>
83 19 Denis 'GNUtoo' Carikli
mount /dev/block/platform/*/by-name/USERDATA /data
84 1 Denis 'GNUtoo' Carikli
</pre>
85
86 34 Denis 'GNUtoo' Carikli
h4. Galaxy Nexus (GT-I9250)
87
88 31 Denis 'GNUtoo' Carikli
For the Galaxy Nexus (GT-I9250), this can be done from your computer with this command:
89
<pre>
90
mount /dev/block/platform/*/*/by-name/userdata /data
91
</pre>
92
93 37 Denis 'GNUtoo' Carikli
h4. Galaxy Nexus (GT-I9250)
94
95
For the Galaxy Nexus (GT-I9250), this can be done from your computer with this command:
96
<pre>
97
mount /dev/block/platform/*/*/by-name/userdata /data
98
</pre>
99
100
h4. Galaxy Tab 2 (GT-P3100, GT-P3110, GT-P5100, GT-P3510)
101
102
For the Tab 2 (GT-P3100, GT-P3110, GT-P5100, GT-P3510), this can be done from your computer with this command:
103
104
<pre>
105
mount /dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS /data
106
</pre>
107
108 34 Denis 'GNUtoo' Carikli
h3. Archiving the data
109
110 19 Denis 'GNUtoo' Carikli
We will then create an archive of the silence data. 
111
112
This makes things much easier because with an archive:
113
* We can easily store and move that data.
114
* The archive preserves all its permissions, and it's best to keep them as applications might not work correctly otherwise. For instance in GNU/Linux, the 'sshd' program will refuse to work if some of its configuration files have the wrong permissions.
115
116
The silence data is in @/data/data/org.smssecure.smssecure/@. To make sure that the archive is created correctly and that once decompressed it will create the @org.smssecure.smssecure@ directory (with all the silence data in it) in the current directory, we need to go to @/data/data@ first.
117
118
To do that, we can go in /data/data with the following command:
119 1 Denis 'GNUtoo' Carikli
<pre>
120 19 Denis 'GNUtoo' Carikli
cd /data/data
121 17 Denis 'GNUtoo' Carikli
</pre>
122 16 Denis 'GNUtoo' Carikli
123 19 Denis 'GNUtoo' Carikli
We can then create the archive in the recovery with that command:
124 1 Denis 'GNUtoo' Carikli
<pre>
125
root@m0:/data/data # tar cvpf /org.smssecure.smssecure.tar org.smssecure.smssecure/
126
</pre>
127
128 19 Denis 'GNUtoo' Carikli
This will create the @/org.smssecure.smssecure.tar@ file which is our archive.
129
130
We will then exit the recovery shell as we will then need to type commands on your computer.
131
132
You can exit the recovery shell with the following command:
133 1 Denis 'GNUtoo' Carikli
<pre>
134
root@m0:/ # exit
135
</pre>
136
137 19 Denis 'GNUtoo' Carikli
We're now back on your computer.
138
139 34 Denis 'GNUtoo' Carikli
h3. Copying the application data on your computer
140
141 19 Denis 'GNUtoo' Carikli
As for now, we've created the archive but it's still in the recovery, so we need to copy it to your computer. 
142
143
This can be done with the following command:
144 1 Denis 'GNUtoo' Carikli
<pre>
145
$ adb pull /org.smssecure.smssecure.tar ./
146
</pre>
147
148 19 Denis 'GNUtoo' Carikli
It will create the @org.smssecure.smssecure.tar@ file in the current directory.
149
150
We will then need to verify that the archive was created correctly. 
151
More precisely we need to check that it will be extracted in the @org.smssecure.smssecure/@ directory, in the current directory, otherwise it could mess up the data partition when it's being uncompressed.
152
153
To do that we can list its content with the following command:
154 23 Denis 'GNUtoo' Carikli
<pre>
155 16 Denis 'GNUtoo' Carikli
tar tvf org.smssecure.smssecure.tar
156 1 Denis 'GNUtoo' Carikli
</pre>
157 19 Denis 'GNUtoo' Carikli
158 17 Denis 'GNUtoo' Carikli
It should output something that will look more or less like that:
159 1 Denis 'GNUtoo' Carikli
<pre>
160
drwxr-x--x u0_a61/u0_a61     0 2020-10-28 18:58 org.smssecure.smssecure/
161
lrwxrwxrwx root/root         0 2020-10-28 18:58 org.smssecure.smssecure/lib -> /data/app/org.smssecure.smssecure-1/lib/arm
162 17 Denis 'GNUtoo' Carikli
[...]
163 19 Denis 'GNUtoo' Carikli
</pre>
164 1 Denis 'GNUtoo' Carikli
What is important to check is that the files and directories starts with @org/smssecure.smssecure/@ or @./org.smssecure.smssecure/@. If not something went wrong during the creation of the backup (for instance you might have forgetten to go in the @/data/data/@ recovery, or this tutorial could contain mistakes or be out of date).
165
166 34 Denis 'GNUtoo' Carikli
h3. Unmounting the data partition
167
168
Now that the backup is done, we can finally unmount the data partition and reboot the device.
169 23 Denis 'GNUtoo' Carikli
170
To do that, we need to go back in the device recovery with the following command:
171
<pre>
172
adb shell
173 24 Denis 'GNUtoo' Carikli
</pre>
174 23 Denis 'GNUtoo' Carikli
175
It should output something that looks more or less like that:
176
<pre>
177
root@m0:/ #
178
</pre>
179
180
To do that first we need to go outside of data, else the mount will fail. This can be done with this command:
181
<pre>
182
cd /
183
</pre>
184
185
Then we can simply unmount /data/ with this command:
186
<pre>
187
umount  /data/
188
</pre>
189
190
Then it's a good practice to make sure that everything is written to the data partition before rebooting.
191
We can do that with this command:
192
<pre>
193
sync
194
</pre>
195
196 25 Denis 'GNUtoo' Carikli
And we can finally reboot or shutdown the device.
197 23 Denis 'GNUtoo' Carikli
198 25 Denis 'GNUtoo' Carikli
Rebooting can be done by selecting @Reboot system now@ in the recovery menu.
199
Shutting down the device can be done by selecting @Power off@ in @Advanced@  in the recovery menu.
200
201 14 Denis 'GNUtoo' Carikli
h2. Restoring Silence's data to the new device
202
203 21 Denis 'GNUtoo' Carikli
In the previous section, we did a backup of silence data that is now contained in the org.smssecure.smssecure.tar archive that you have on your computer.
204 1 Denis 'GNUtoo' Carikli
205 21 Denis 'GNUtoo' Carikli
In this section, we will restore that archive to a new device.
206 1 Denis 'GNUtoo' Carikli
207 21 Denis 'GNUtoo' Carikli
First you need to install silence, and if possible, give it the same permissions it had before. If not, we can still fix that later as silence is not required to boot the device, so we can still access the Android settings and fix that afterward. 
208
209
Silence is installed before restoring its data for several reasons:
210
* We need to give it the necessary permissions. If you don't do that it might crash at startup once the data is restored. However it's still possible to fix it when it happens.
211
* We need a new @/data/data/org.smssecure.smssecure@ directory to be created to be able to easily find the new username in which silence is running, as right after restoring the backup will need to fix the permissions of the new data to use this new username.
212
213
Once Silence is installed, you will also need to enable root shells in the recovery like you did when doing a backup of Silence data.
214
215
Here too, it's done this way to make sure that the application isn't writing to its data while you are restoring the data from the older device.
216
217
To make sure of that, here too, the easiest way to do that is to go in the recovery: this way the application will not be started automatically and the data will be restored while the application isn't started.
218
219
You will also need a root shell in the recovery of this new device, so make sure to setup that beforehand.
220
221
If everything is setup correctly, running @adb shell@ from your computer should result in a shell that now looks like this:
222 1 Denis 'GNUtoo' Carikli
<pre>
223 21 Denis 'GNUtoo' Carikli
root@m0:/ #
224 1 Denis 'GNUtoo' Carikli
</pre>
225
226 35 Denis 'GNUtoo' Carikli
h3. Mounting the data partition
227
228 21 Denis 'GNUtoo' Carikli
Once that you have a shell in the recovery, you need to mount the data partition in /data from within that shell.
229 33 Denis 'GNUtoo' Carikli
230 36 Denis 'GNUtoo' Carikli
h4. Galaxy SII (GT-I9100)
231
232 33 Denis 'GNUtoo' Carikli
For the Galaxy SII (GT-I9100), this can be done from your computer with this command:
233
<pre>
234
mount /dev/block/platform/*/by-name/DATAFS /data
235
</pre>
236 21 Denis 'GNUtoo' Carikli
237 36 Denis 'GNUtoo' Carikli
h4. Galaxy SIII (GT-I9300)
238
239 21 Denis 'GNUtoo' Carikli
For the Galaxy SIII (GT-I9300), this can be done from your computer with this command:
240 5 Denis 'GNUtoo' Carikli
<pre>
241 21 Denis 'GNUtoo' Carikli
mount /dev/block/platform/*/by-name/USERDATA /data
242 5 Denis 'GNUtoo' Carikli
</pre>
243 36 Denis 'GNUtoo' Carikli
244
h4. Galaxy Nexus (GT-I9250)
245 7 Denis 'GNUtoo' Carikli
246 32 Denis 'GNUtoo' Carikli
For the Galaxy Nexus (GT-I9250), this can be done from your computer with this command:
247
<pre>
248
mount /dev/block/platform/*/*/by-name/userdata /data
249
</pre>
250
251 35 Denis 'GNUtoo' Carikli
h3. Before restoring the archive
252
253 21 Denis 'GNUtoo' Carikli
If we extract the archive we made eariler, it will create the @org.smssecure.smssecure@ directory and extract everything in it. 
254 7 Denis 'GNUtoo' Carikli
255 21 Denis 'GNUtoo' Carikli
Since the data of Silence is in @/data/data/org.smssecure.smssecure/@ we then need to go in @/data/data@ before extracting the archive. This way when extracting it, everything will be at the place it's supposed to be.
256 5 Denis 'GNUtoo' Carikli
257 21 Denis 'GNUtoo' Carikli
To do that, we can go in /data/data with the following command:
258
<pre>
259
cd /data/data
260
</pre>
261 5 Denis 'GNUtoo' Carikli
262 21 Denis 'GNUtoo' Carikli
However we can't restore Silence data yet as:
263
* It could mix both data sets.
264
* We need some information (silence username) contained in the new silence data.
265 1 Denis 'GNUtoo' Carikli
266 21 Denis 'GNUtoo' Carikli
As applications are sandboxed, and that as part of that sandboxing, they have their own usernames, we need to retrieve this username, as we'll reuse it to fix the restored silence data permissions.
267 1 Denis 'GNUtoo' Carikli
268 21 Denis 'GNUtoo' Carikli
To get that username we can just use @ls -ld@ on the directory holding the internal data of the newly installed silence (which is in @/data/data/org.smssecure.ssmsecure@).
269 1 Denis 'GNUtoo' Carikli
270
So with @ls -ld@ we can find the application username in this way:
271
<pre>
272
root@m0:/data/data # ls -ld org.smssecure.smssecure
273
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
274 5 Denis 'GNUtoo' Carikli
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
275
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
276 1 Denis 'GNUtoo' Carikli
drwxr-x--x 2 u0_a61 u0_a61 4096 2012-01-01 00:01 org.smssecure.smssecure
277 3 Denis 'GNUtoo' Carikli
</pre>
278
279 1 Denis 'GNUtoo' Carikli
Here the users and groups are @u0_a61@.
280 5 Denis 'GNUtoo' Carikli
281 21 Denis 'GNUtoo' Carikli
We will then need use this information later on to restore the silence data from the other device: If we restore Silence's data as-is it will most likely have wrong permissions: when the the Silence application was installed on the older device, it was assigned an username. As this username depends on the number of applications that were installed before it, we cannot expect it to always be the same between the two devices.
282 1 Denis 'GNUtoo' Carikli
283 21 Denis 'GNUtoo' Carikli
We will also move the data of the silence we just installed. Moving it can be done with this command:
284 1 Denis 'GNUtoo' Carikli
<pre>
285 21 Denis 'GNUtoo' Carikli
mv org.smssecure.smssecure org.smssecure.smssecure.delme
286 5 Denis 'GNUtoo' Carikli
</pre>
287 1 Denis 'GNUtoo' Carikli
288 21 Denis 'GNUtoo' Carikli
Moving it has several advantages over just deleting it:
289 1 Denis 'GNUtoo' Carikli
* We can still verify the username later on to see if it matches with the backup we restored.
290
* We can interrupt this tutorial more easily if something goes wrong.
291
292 21 Denis 'GNUtoo' Carikli
To be sure that the data is restored in the right directory, we will need to verify that the archive will extract its files in the @org.smssecure.smssecure@ directory and not directly in the current directory (which should be @/data/data@ as we moved into it before):
293
294 35 Denis 'GNUtoo' Carikli
h3. Restoring the archive
295
296 21 Denis 'GNUtoo' Carikli
The archive can be verified with the following command:
297 1 Denis 'GNUtoo' Carikli
<pre>
298 21 Denis 'GNUtoo' Carikli
tar tf /org.smssecure.smssecure.tar
299
</pre>
300
301
It will output something that looks a bit like that:
302
<pre>
303 1 Denis 'GNUtoo' Carikli
./org.smssecure.smssecure/
304 5 Denis 'GNUtoo' Carikli
./org.smssecure.smssecure/lib -> /data/app/org.smssecure.smssecure-1/lib/arm
305 1 Denis 'GNUtoo' Carikli
[...]
306
</pre>
307 21 Denis 'GNUtoo' Carikli
We will need to verify that everything starts with @./org.smssecure.smssecure/@ or @org.smssecure.smssecure/@. Here it is the case, so the archive is good.
308 1 Denis 'GNUtoo' Carikli
309 5 Denis 'GNUtoo' Carikli
If we had something like that instead:
310 1 Denis 'GNUtoo' Carikli
<pre>
311
root@m0:/data/data # tar tf /org.smssecure.smssecure.tar
312
./lib -> /data/app/org.smssecure.smssecure-1/lib/arm
313
[...]
314
</pre>
315
316 21 Denis 'GNUtoo' Carikli
Then it's best to recreate the archive. In that case, if you want to abort to restart later on, you could also move back org.smssecure.smsecure.delme to org.smssecure.smssecure if needed.
317 5 Denis 'GNUtoo' Carikli
318 21 Denis 'GNUtoo' Carikli
If the archive was good, we can then proceed to extract the application data.
319
320 5 Denis 'GNUtoo' Carikli
This can be done with the following command:
321 21 Denis 'GNUtoo' Carikli
<pre>
322 3 Denis 'GNUtoo' Carikli
tar xpf /org.smssecure.smssecure.tar --numeric-owner
323 5 Denis 'GNUtoo' Carikli
</pre>
324 1 Denis 'GNUtoo' Carikli
325 35 Denis 'GNUtoo' Carikli
h3. Fixing the Unix permissions
326
327
If we look at the data we just restored, we can see that the username differs from the one we need with the following command:
328 3 Denis 'GNUtoo' Carikli
<pre>
329 21 Denis 'GNUtoo' Carikli
ls -ld org.smssecure.smssecure 
330
</pre>
331
332
It should then print something like that ( the lines starting with @__bionic_open_tzdata:@ can be ignored):
333
<pre>
334 3 Denis 'GNUtoo' Carikli
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
335 1 Denis 'GNUtoo' Carikli
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
336 5 Denis 'GNUtoo' Carikli
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
337 3 Denis 'GNUtoo' Carikli
drwxr-x--x 9 u0_a63 u0_a63 4096 2012-01-01 00:21 org.smssecure.smssecure
338 1 Denis 'GNUtoo' Carikli
</pre>
339 35 Denis 'GNUtoo' Carikli
340 21 Denis 'GNUtoo' Carikli
Here we have @u0_a63@, while the new silence data used @u0_a61@, so we need to fix it.
341 5 Denis 'GNUtoo' Carikli
342 21 Denis 'GNUtoo' Carikli
This can be done with the @chown@ command, like that:
343 3 Denis 'GNUtoo' Carikli
<pre>
344
root@m0:/data/data # chown u0_a61:u0_a61 -R org.smssecure.smssecure            
345
root@m0:/data/data # 
346
</pre>
347 21 Denis 'GNUtoo' Carikli
You need to replace @u0_a61@ by the username you found earlier.
348 1 Denis 'GNUtoo' Carikli
349 21 Denis 'GNUtoo' Carikli
When this is done, we don't need the @org.smssecure.smssecure.delme@ directory anymore, and it's best to remove it not to create any issues later on.
350
351 1 Denis 'GNUtoo' Carikli
This can be done with the following command:
352 3 Denis 'GNUtoo' Carikli
<pre>
353 21 Denis 'GNUtoo' Carikli
rm -rf org.smssecure.smssecure.delme
354 1 Denis 'GNUtoo' Carikli
</pre>
355
356 21 Denis 'GNUtoo' Carikli
If everything went fine, it shouldn't output anything.
357 1 Denis 'GNUtoo' Carikli
358 35 Denis 'GNUtoo' Carikli
h3. Fixing the Selinux permissions
359
360 21 Denis 'GNUtoo' Carikli
We are not done yet at restoring the permissions as in addition to the standard unix permissions which we just fixed, Android also uses selinux, which also has its own permissions.
361
362
The restorecon command can be used to fixup selinux permissions.
363
364
Here's its help (it can be shown just by typing @restorecon@):
365 1 Denis 'GNUtoo' Carikli
<pre>
366
usage: restorecon [-D] [-F] [-R] [-n] [-v] FILE...
367 5 Denis 'GNUtoo' Carikli
368 1 Denis 'GNUtoo' Carikli
Restores the default security contexts for the given files.
369
370
-D	apply to /data/data too
371
-F	force reset
372
-R	recurse into directories
373 6 Denis 'GNUtoo' Carikli
-n	don't make any changes; useful with -v to see what would change
374
-v	verbose: show any changes
375
376 5 Denis 'GNUtoo' Carikli
restorecon: Needs 1 argument
377
</pre>
378 3 Denis 'GNUtoo' Carikli
379
So to use it to fixup the selinux permissions, we can use the following command:
380
<pre>
381 21 Denis 'GNUtoo' Carikli
restorecon -D -F -R -v /data/
382 1 Denis 'GNUtoo' Carikli
</pre>
383
384
The order of the arguments (-D, -F, etc) seem to be important here as the wrong order might result in nothing being done.
385
Without the @-v@ argument and with the wrong order of argument, it might make you think that it did its job while it did nothing.
386
387
It will then print something that looks like that:
388
<pre>
389
SELinux: Loaded file_contexts contexts from /file_contexts.
390
[...]
391
SELinux:  Relabeling /data/data/org.smssecure.smssecure from u:object_r:system_data_file:s0 to u:object_r:app_data_file:s0:c512,c768.
392
SELinux:  Relabeling /data/data/org.smssecure.smssecure/lib from u:object_r:system_data_file:s0 to u:object_r:app_data_file:s0:c512,c768.
393
[...]
394
</pre>
395
396
Now the permissions fixing is finally done.
397 35 Denis 'GNUtoo' Carikli
398
h3. Unmounting the data partition and rebooting the device
399 1 Denis 'GNUtoo' Carikli
400 21 Denis 'GNUtoo' Carikli
we can then umount the data partition and reboot.
401 1 Denis 'GNUtoo' Carikli
402 21 Denis 'GNUtoo' Carikli
To do that first we need to go outside of data, else the mount will fail. This can be done with this command:
403 1 Denis 'GNUtoo' Carikli
<pre>
404 21 Denis 'GNUtoo' Carikli
cd /
405 1 Denis 'GNUtoo' Carikli
</pre>
406 3 Denis 'GNUtoo' Carikli
407 21 Denis 'GNUtoo' Carikli
Then we can simply unmount /data/ with this command:
408 1 Denis 'GNUtoo' Carikli
<pre>
409 21 Denis 'GNUtoo' Carikli
umount  /data/
410 5 Denis 'GNUtoo' Carikli
</pre>
411
412
Then it's a good practice to make sure that everything is written to the data partition before rebooting.
413 21 Denis 'GNUtoo' Carikli
We can do that with this command:
414 1 Denis 'GNUtoo' Carikli
<pre>
415 21 Denis 'GNUtoo' Carikli
sync
416 1 Denis 'GNUtoo' Carikli
</pre>
417 16 Denis 'GNUtoo' Carikli
418 25 Denis 'GNUtoo' Carikli
And we can finally reboot or shutdown the device.
419
420
Rebooting can be done by selecting @Reboot system now@ in the recovery menu.
421
Shutting down the device can be done by selecting @Power off@ in @Advanced@  in the recovery menu.
422 5 Denis 'GNUtoo' Carikli
423 21 Denis 'GNUtoo' Carikli
h2. How to fix Silence if it still refuses to start with the restored data.
424 1 Denis 'GNUtoo' Carikli
425 21 Denis 'GNUtoo' Carikli
After rebooting, silence may still refuse to start if it doesn't have the right permissions.
426
427
To identify if it doesn't start due to missing permissions, you can use the following command from your computer:
428 1 Denis 'GNUtoo' Carikli
<pre>
429 21 Denis 'GNUtoo' Carikli
adb logcat -b main
430 5 Denis 'GNUtoo' Carikli
</pre>
431
432 21 Denis 'GNUtoo' Carikli
Then you need to wait until no more new logs were printed, otherwise it'd be harder to find the crash we're looking for in this huge amount of logs.
433 5 Denis 'GNUtoo' Carikli
434 21 Denis 'GNUtoo' Carikli
To better identify where the part where Silence crash starts and stops, you could for instance create a separation in the logs being printed by adding
435
many new lines once no more logs are printed, right before launching silence. This can be done by pressing enter multiple times or by pressing many time a character like @=@ to create a visible line.
436 1 Denis 'GNUtoo' Carikli
437 21 Denis 'GNUtoo' Carikli
You can then launch silence, and as soon as the crash is done, do the same to mark the end, not to have too much logs to read.
438
439
When Silence crashed, the following appeard in the logs:
440
<pre>
441 5 Denis 'GNUtoo' Carikli
01-01 01:27:48.260  4126  4126 D AndroidRuntime: Shutting down VM
442
01-01 01:27:48.265  4126  4126 E AndroidRuntime: FATAL EXCEPTION: main
443
01-01 01:27:48.265  4126  4126 E AndroidRuntime: Process: org.smssecure.smssecure, PID: 4126
444
01-01 01:27:48.265  4126  4126 E AndroidRuntime: Theme: themes:{}
445
01-01 01:27:48.265  4126  4126 E AndroidRuntime: java.lang.RuntimeException: Unable to create application org.smssecure.smssecure.ApplicationContext: java.lang.SecurityException: getActiveSubscriptionInfoList: Neither user 10061 nor current process has android.permission.READ_PHONE_STATE.
446
01-01 01:27:48.265  4126  4126 E AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4754)
447 1 Denis 'GNUtoo' Carikli
[...]
448 5 Denis 'GNUtoo' Carikli
</pre>
449
450 21 Denis 'GNUtoo' Carikli
Here we can clearly see that it's a permission issue as it says that @Neither user 10061 nor current process has android.permission.READ_PHONE_STATE@.
451
And we know it's from silence as it has @Process: org.smssecure.smssecure@.
452 4 Denis 'GNUtoo' Carikli
453 21 Denis 'GNUtoo' Carikli
To fix that issue, I went in @Settings->Apps->Silence->Permissions@ and gave it all the permissions it needed.
454
455
I had this issue because I didn't even launch silence after installing it, so it couldn't ask me for the permissions it needed.
456
457
And the silence of the former device probably wrote in its data that it already asked the permissions not to re-ask for it each time.
458
459
h2. How to find which directory holds the internal data of an application.
460
461
The directories holding the data are in @/data/data/@ and have the internal name of the application.
462
463
Here are some well known name correspondances:
464
465
| Internal name           | Application                                 |
466
| org.smssecure.smssecure | Silence                                     |
467
| com.android.dialer      | Dialer (Android's stock dialer application) |
468
| fil.libre.repwifiapp    | RepWiFi                                     |
469
470
So silence RepWiFi will be @/data/data/fil.libre.repwifiapp@
471
472
For pakcages comming from f-droid, the f-droid website can find the correspondance.
473
474 1 Denis 'GNUtoo' Carikli
For instance the "Silence page":https://f-droid.org/en/packages/org.smssecure.smssecure/ has @org.smssecure.smssecure@ in its URL and inside the page.
475 27 Denis 'GNUtoo' Carikli
476
h2. Revoke USB debugging permissions
477
478
If you don't need @USB debugging permissions@ anymore, it might be a good idea to remove them. The [[ADB#Revoking-all-computers-USB-debugging-permissions|Revoking all computer's USB debugging permissions]] section in the ADB wiki page explains how to do that.
479
480
That's it! Your device's EFS partition is now backed up. Your device should be running Replicant normally again.