Jump to content

Al T

Members
 View Profile  See their activity

  • Content Count

    94

  • Joined

  • Last visited

Posts posted by Al T

  1. Posted · Edited by Al T

    Copying is so much faster than that filling a file.  The time it takes to create a random.txt file filled with random data takes incredibly much longer than just trying to create 1 file.

     

    The process is... Create a file with random data at percentage of the free space available.  Then start copying files. When the size of free space gets close to reaching the free space storage size, it'll create a new random data file and then continue copying files.  This process repeats as the free space gets smaller until it's down to copying bytes of data.

     

    (Edit: My phone starts at stage 11.  When it reaches stage 0 it's almost ready to clean up. You'll see the stage your in ...in [brackets])

     

    My Samsung rings me when the space is empty.  Google pixel goes berserk!  So, your phone will let you know when your out of space..lol.

     

    As far as "cluster sizes".. I haven't read anything on cluster sizes.  I just wanted something basic that will wipe the drive.

     

    I just know, if you write data on a drive multiple times, your practically wiping the drive.

     

    The file location of all the filler files is in your download directory named "FILLER".  If you stop Shred'N'Burn mid way thru, you can tell it not to delete the files.  You can then go "view" the files in that directory.

     

    I do have a road map to add more functions that will increase the smartness of the program.

  2. Posted · Edited by Al T

    Hi,

     

    I'm a freeware developer and have created "Shred'N'Burn" using Delphi 11.0

     

    In the credits of this application, I give credit to Delphi 11.

     

    It took 5 days for Google Play to approve this application.

     

    Main purpose: If you don't know it, most operating systems don't wipe your files before they delete them.  So, Shred'N'Burn utility can wipe the whole storage space by filling it up with random data.

     

    Hint: This Program can take quite a while to run depending on space.  I have about 90gb of free space and I've got a Pixel 6.  It took roughly an 30 minutes to just get a random.txt file created then several hours to fill the space.  This isn't a quick job and can get some phones pretty hot.

     

    There is so many apps that claim they can do this without proof of work.  My application does request permissions to use external storage so it can create a folder called "filler" in the downloads directory.  There it will create a random.txt file that you can view while it's being made.  After that file is created, it will begin to copy it over and over until it fills up all the free storage space.  Once it reaches the end of free storage space, it will automatically clean up by deleting those files. You can watch the process using any file manager.  The process isn't hidden from a users view.

     

    I'll be adding more features, but I really wanted to get this out there for a few of my friends.  One of the major features I plan to add is throttling because it can make some phones get hot.

     

    It's in open testing, so if you use it and have problems, please report them here.  Thank you!

     

    https://play.google.com/store/apps/details?id=com.embarcadero.ShredNBurn

     

  3. Posted

    You need a ARM EABI v7a system image for the emulator to work with Delphi.  The worst part of it is that the latest ARM EABI v7a is in Android 7.1.1 for the SDK Manager using the GUI for Delphi 10.4 as I'm having problems trying to get the GUI for Delphi 11 !!!

  4. Posted · Edited by Al T

    Hi,

     

    I need this so I can use the emulators... I need the emulators to take screenshots of Tablets.

     

    I have installed versions XE8, 10.2, 10.3, 10.4, and 11.  All the versions of Delphi except 11 install with the GUI version of the SDK / AVD managers.  I've been working over the past week trying to figure out how to get a SDK / AVD manager working for Delphi 11 with no luck.

     

    Delphi 11, on its website, says that GetIt Package Manager would do it, but I couldn't find it in GetIt Package Manager.

     

    Does anyone have any idea how I can get the GUI versions of AVD / SDK manager working?  

  5. Posted · Edited by Al T

    Here's the code that works in Delphi 11, but it wont work in XE8 because "[DCC Error] Unit1.pas(210): E2003 Undeclared identifier: 'TAndroidHelper'

     

      

    unit Unit1;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  System.Math,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs,
  IdBaseComponent, IdThreadComponent, FMX.StdCtrls, FMX.Layouts,
  FMX.Controls.Presentation, FMX.ScrollBox, FMX.Memo, System.IOUtils,
  AndroidAPI.JNIBridge,
  Androidapi.JNI.JavaTypes,
  android.os.StatFs,
  Posix.Unistd, FMX.Memo.Types, Unit2, System.ImageList, FMX.ImgList,
  Androidapi.Log,
  Androidapi.JNI.App,
  Androidapi.JNI.GraphicsContentViewText,
  Androidapi.Helpers,
  credits, OptionsUnit;
  
{ MISC CODE IN BETWEEN }

function AndroidGetMemory: Int64;
var
  MemoryInfo: JActivityManager_MemoryInfo;
  AvailMb: Int64;
begin
  MemoryInfo:= TJActivityManager_MemoryInfo.JavaClass.init;
  TJActivityManager.Wrap((TAndroidHelper.Context.getSystemService(
    TJContext.JavaClass.ACTIVITY_SERVICE) as ILocalObject).GetObjectID)
    .getMemoryInfo(MemoryInfo);
  AvailMb := MemoryInfo.availMem;
  result := AvailMb;
end;

    I found the problem in the code above and changed it to this: 

    uses
  Androidapi.Helpers,
  Androidapi.JNIBridge,
  Androidapi.JNI.GraphicsContentViewText,
  Androidapi.JNI.App;




function AndroidGetMemory: Int64;
var
  MemoryInfo: JActivityManager_MemoryInfo;
//  TotalMb: Int64;
  AvailMb: Int64;
begin
  MemoryInfo:= TJActivityManager_MemoryInfo.JavaClass.init;

  TJActivityManager.Wrap((SharedActivityContext.getSystemService(
    TJContext.JavaClass.ACTIVITY_SERVICE) as ILocalObject).GetObjectID)
    .getMemoryInfo(MemoryInfo);
  //TotalMb:= MemoryInfo.totalMem shr 20;
  //AvailMb:= MemoryInfo.availMem shr 20; in MB
  AvailMb:= MemoryInfo.availMem;
  result := AvailMb;
end;

    SharedActivityContext was deprecated in Delphi 11 and uses TAndroidHelper.Context

  7. Posted

    I assumed Delphi could handle 64-bit code, since they claim they have 64-bit compilers, but after doing some research it seems they haven't made case statements compatible with 64-bits:

     

    "where selectorExpression is any expression of an ordinal type smaller than 32 bits (string types and ordinals larger than 32 bits are invalid) and each caseList is one of the following:" from https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Declarations_and_Statements_(Delphi)#Case_Statements

     

    I have the enterprise version... Could I make the case statement use 64-bit integers?  Or maybe create a 64-bit case?

  10. Posted · Edited by Al T

    If you swap them, you get error "Duplicate case label".  What to do?

      

    function cntCaseTbl(Z: Int64): Int64;
  begin
    case Z of
      0..9: Exit(1);
      10..99 : Exit(2);
      100..999: Exit(3);
      1000..9999: Exit(4);
      10000..99999: Exit(5);
      100000..999999: Exit(6);
      1000000..9999999: Exit(7);
      10000000..99999999: Exit(8);
      100000000..999999999: Exit(9);
      1000000000..9999999999: Exit(10);
      10000000000..99999999999: Exit(11); //<--------Low bound exceeds high bound
      100000000000..999999999999: Exit(12); //<--------Low bound exceeds high bound
      1000000000000..9999999999999: Exit(13); //<--------Duplicate case label
      10000000000000..99999999999999: Exit(14); //<--------Low bound exceeds high bound
      100000000000000..999999999999999: Exit(15); //<--------Low bound exceeds high bound
      1000000000000000..9999999999999999: Exit(16); //<--------Duplicate case label
      10000000000000000..99999999999999999: Exit(17); //<--------Low bound exceeds high bound
      100000000000000000..999999999999999999: Exit(18); //<--------Low bound exceeds high bound
      1000000000000000000..9223372036854775807: Exit(19); //<--------Duplicate case label
    end;
  end;

     

  11. Posted

    10 hours ago, SwiftExpat said:

    You can start multiple instance(s) of the IDE, that seems like a logical way to debug your applications. Instance 1 you would select phone 1 and Instance 2, select phone 2.

    I am more curious about the behavior of Android, does the OS ever kill your application? Or does it seem stable?

    Running multiple instances... might cause issues... but I'll try.

     

    I've not had the Android kill my OS while doing long tasks... sometimes I'll lay back and watch YouTube while a task is running on one of the devices.  Android OS doesn't kill the app while it is running in the background.  I've left the phone doing one of these tasks over night and the next morning it was still running.

  12. Posted · Edited by Al T

    3 hours ago, Brian Evans said:

    You can run/debug multiple executables in a project group at the same time. Build all the project group (you can't compile one while the other is running) then run each in turn. A quick test has a local Windows 64 bit app window and one on Linux VM.

    RunMultipleProjectGroup.png

    Nice, but doesn't work for Android.  I Setup another folder and copied the first project to the new folder... then I build all.  Both projects build.  I run the first project and wait for it to load on the first android... then go to the next project, double click on it to make it BOLD... right click on the second project and the RUN and the RUN without debugging is Disabled!

     

    So... I was really hoping it would work.  Both Phones show up as targets that can be used... just you can't run them both.

     

    The odd thing is... I've read that Android Studio can do multiple phones at the same time.  Was hoping that Delphi could do the same.

     

     

  13. Posted · Edited by Al T

    15 hours ago, Dave Nottage said:

    I doubt it is possible with one instance of Delphi. Might be better to explain why you need it - there may be an alternative.

    I hope this don't offend you, but it's pretty obvious why one would want to run debug on both phones at the same time.

     

    1. You don't have to run debug "twice", which means switching phone menu, waiting for a recompile ...etc...

    2. While one application is running it's task, you can setup the other application to run it's task.  (Two tasks running at the same time is better than having to repeat the process and time to weight again and again)

     

    Based on my previous posts here on these forums, someone might actually know I'm moving around data / copying data.  It's going to be large amounts of data on mobile phones.  I need to wait for the task to complete and for it to do it right.  It can take hours for the task to complete.  Doing one phone at a time is very time consuming.

     

    The tasks I have my phone doing for an application can take up to an hour before the "bug" would hit.... If I could run that task on both phones at the same time, I would save myself time in trying to find that issue.  I would then have two reference points going instead of one.  Especially trying to hunt down any segmentation faults that nobody likes to help with...then it ends up being the fault of Delphi not being able to keep up with itself.... memo1.lines tends to have issues with fast updating in Android and will constantly fault when it says lines are over-lapping.  Also like in a early situation where I found out that updating label component too fast in Android creates a segment fault because it was running in separate threads and two or more threads would over-lap and try to update the same component.

     

    *** Overall: Having two phones and being able to debug them both... especially when the tasks can take hours to complete... would be a major plus.   I understand a lot of apps don't require such long tasks... but some do.  It would be a major plus to be able to debug two or more phones at the same time.

     

    I could "cheat" and make the tasks take less time by shortening how much data has to be moved around, but it won't replicate real world problems.  I'd rather just wait to make sure the tasks are repeatedly have no bugs.

     

  14. Posted · Edited by Al T

    15 hours ago, Dave Nottage said:

    I'd expect that behaviour if CopyData was running in a separate thread. It would not normally be an issue, otherwise.

    CopyDate is called by a thread component (which is on a constant loop until the stop button is pressed or the program stops the thread):

      

    procedure TForm1.IdThreadComponent1Run(Sender: TIdThreadComponent);
begin
  if ((OptionsUnit.OptionsForm.CleanUpBox.IsChecked = true)
  and (DeleteFiles = true) and (breakit=true)
  and (copydataActive = false)
  and (DeleteInProgress = false)) then
  begin
    AniIndicator1.Enabled := true;
    DeleteData();
  end;

  if ((copydataActive = false) and (breakit = false) and (DeleteFiles = false) and (DeleteInProgress = false)) then  //breakit = true don't create files
  begin
    AniIndicator1.Enabled := true;
    CopyData();
  end;

sleep(250);
end;

     

    I think I understand... the label and copydata need to be in separate threads?

     

  17. Posted · Edited by Al T

    [Solved Second Post]

     

    Hi...

     

    I had found out in a previous question that my Segment Fault was caused by LabelLine1.Text.

     

    Now I'm trying to figure out how to use Label.Text without creating a Segment Fault 11?

     

    I've already tried LabelLine1.BeginUpdate / EndUpdate... that doesn't stop the Segment Fault... what else could I do?


      

          while FileNameCounter<126 do
      begin
        inc(FileNameCounter);

        RandomFileName := FolderArea + TPath.DirectorySeparatorChar + 'ran' + IntToStr(FileNameCounter) + '.txt';

        try
          LabelLine1.BeginUpdate;
          LabelLine1.Text := 'Creating: ran' + IntToStr(FileNameCounter) + '.txt'; // May cause Segment Fault 11
          LabelLine1.EndUpdate;

          dString('Create RandomFile:'+RandomFileName);  //could write a TStringList and save to it... later savetofile
          //sleep(500); //dString writes to a file log file.
          MemoryCopyToFile(RandomFileName);
        Except
          On E: Exception Do
          begin
            dString('TFile.Copy(RandomFileToCopy, RandomFileName):'+E.ClassName + ' ERROR: ' + E.Message);
            breakit := true; //break on error
          end;
        end;

        if breakit = true then exit;

      end;

     

  18. Posted

    Solved the issue:

    For some reason Delphi 11 and Android 9 & 12 do not like refreshing LabelLine1.Text ... it will cause a segment fault refreshing it.  I don't understand... but after commenting that line out just before the copying of a file makes it run perfectly!   Even though memo1.lines is in dString... the LabelLine1.Text was the issue!  This is the DEFAULT Label component that comes with Delphi 11 Enterprise!  I wonder if Skia Label will handle better?

      

          try
        //if FileExists(RandomFileName) = true then DeleteFile(RandomFileName);
------->LabelLine1.Text := 'Creating: ran' + IntToStr(FileNameCounter) + '.txt';
        dString('Create RandomFile:'+RandomFileName);
        sleep(50); //dString writes to a file log file.
        TFile.Copy(RandomFileToCopy, RandomFileName, true);
      Except
        On E: Exception Do
        begin
          dString('TFile.Copy(RandomFileToCopy, RandomFileName):'+E.ClassName + ' ERROR: ' + E.Message);
          breakit := true; //break on error
        end;
      end;

  19. Posted · Edited by Al T

    [See 2nd Post on Solution]

     

    I keep hitting this road-block.  There no source code it's pointing to.  It's just pointing to CPU assembly code.  It's always the same segment fault.  How do I trace it down?

     

    The segment fault happens when it gets around 33 or 34 files of ran*.txt.  There's plenty of space left to create hundreds more files, but it likes to stop around 33 or 34 on the ran*.txt Tfile.copy?  I added true to the end of it... but the overwrite parameter didn't help.

     

    Error:

    BFD: C:/Users/alt/Documents/Embarcadero/Studio/Projects/Filler/Android/Debug/FSP/debug/linker: don't know how to handle section `.relr.dyn' [0x      13]

    Process FSP.apk (4871)
    [Switching to Thread 5055]  Process FSP.apk (4871)

     

    First chance exception at $BD9F069E. Exception class Segmentation fault (11). Process FSP.apk (4871)

     

    BD9F069E F8525023         ldr.w r5, [r2, r3, lsl #2]
    BD9F06A2 BF08             it eq
    BD9F06A4 2608             moveq r6, #8
    BD9F06A6 4281             cmp r1, r0
    BD9F06A8 EA460605         orr.w r6, r6, r5
    BD9F06AC F8426023         str.w r6, [r2, r3, lsl #2]
    BD9F06B0 D1EE             bne.n 0xbd9f0690

     

    call stack thread

    --> :BD9F069E ??()
    :BD9A21A6 ??()
    :BD9A21A6 ??()

     

    it doesn't tell me where the error is... but I suspect it to be in this procedure because it's in the middle of creating the ran*.txt files:

     

    Global variables: 

    var
  Form1: TForm1;
  FileDirectory, RandomFileToCopy: String;
  FilePermissions, DeleteFiles, DeleteInProgress: boolean;
  DeleteDirectoryList: TArray<system.string>;
  MaxFreeSpace: Int64;
  debugLines: TStrings;
  dButtonPreviousIsPressed: boolean;
  breakit: boolean;
  copydataActive: boolean;

const
  FillerDiectoryNameConst = 'FILLER';

    Procedure that I believe to be causing the segment fault:
      

    procedure TForm1.CopyData();
var
  DriveStr : String;
  FileNameCounter : integer;
  FolderCounter : integer;
  FolderName : string;
  FolderArea : string;
  RandomFileName : String;
begin
  copydataActive := true;
  RandomFileToCopy := '';

  FileNameCounter := 0;
  FolderCounter := 0;

  DriveStr := FileDirectory + TPath.DirectorySeparatorChar;

  RandomFileToCopy := DriveStr + 'random.txt';

  // create random file
  //CreateNewRandFile(64000000); //64 mb file
  CreateNewRandFile(640); //640 file for testing purposes

  inc(FolderCounter);
  FolderName := 'rand' + IntToStr(FolderCounter);

  FolderArea := FileDirectory + TPath.DirectorySeparatorChar + FolderName;

  LabelLine2.Text := '';

  while DirectoryExists(FolderArea) = true do
  begin
    inc(FolderCounter);
    FolderName := 'rand' + IntToStr(FolderCounter);
    FolderArea := FileDirectory + TPath.DirectorySeparatorChar + FolderName;

    LabelLine1.Text := 'Folder: ' + FolderName;

    if breakit = true then exit;
  end;

  try
    TDirectory.CreateDirectory(FolderArea);
    dString('CreateDirectory:'+FolderArea);
  except
    on E : Exception do
      begin
        dString('CreateDirectory(FolderArea):'+E.ClassName+' error: '+E.Message);
        copydataActive := false;
        exit;
      end;
  end;

  while CheckDiskSize(FolderArea) > 0 do
  begin
    if breakit = true then exit;

    RandomFileName := FolderArea + 'ran' + IntToStr(FileNameCounter) + '.txt';

    FileNameCounter := 0;

    while FileNameCounter<126 do
    begin
      inc(FileNameCounter);

      RandomFileName := FolderArea + TPath.DirectorySeparatorChar + 'ran' + IntToStr(FileNameCounter) + '.txt';

      try
        //if FileExists(RandomFileName) = true then DeleteFile(RandomFileName);
        LabelLine1.Text := 'Creating: ran' + IntToStr(FileNameCounter) + '.txt';
        dString('Create RandomFile:'+RandomFileName);
        sleep(50); //dString writes to a file log file.
        TFile.Copy(RandomFileToCopy, RandomFileName, true);
      Except
        On E: Exception Do
        begin
          dString('TFile.Copy(RandomFileToCopy, RandomFileName):'+E.ClassName + ' ERROR: ' + E.Message);
          breakit := true; //break on error
        end;
      end;

      if breakit = true then exit;

    end;

    while DirectoryExists(FolderArea) = true do
    begin
      inc(FolderCounter);
      FolderName := 'rand' + IntToStr(FolderCounter);
      FolderArea := FileDirectory + TPath.DirectorySeparatorChar + FolderName;

      LabelLine1.Text := 'Folder: ' + FolderName;

      if breakit = true then exit;
    end;

    // all else fails... and it still is true... exit
    if DirectoryExists(FolderArea) = true then
    begin
      copydataActive := false;
      exit;
    end;

    try
      TDirectory.CreateDirectory(FolderArea);
      dString('CreateDirectory:'+FolderArea);
    except
      on E : Exception do
        begin
          dString('CreateDirectory(FolderArea):'+E.ClassName+' error: '+E.Message);
          copydataActive := false;
          exit;
        end;
    end;

  end;

  copydataActive := false;
end;

     

×